我很难理解Graphite和Kibana 3的集成来监控日志和系统命中率 . 我指的是Log management system described here中的数字 .
-
考虑到Kibana 3 Milestone 4中的新功能，我们是否可以收集系统命中注意事项并将其直接存储到弹性搜索中而不是石墨中，并使用单个kibana仪表板（在重点关注性能的分布式系统中实施什么是正确的选择？低记忆足印）？
-
为什么我们必须使用StatsD和石墨，当计数和简单统计现在由kibana支持 - Elasticsearch组合？
-
如果我们决定同时使用石墨和kibana，我们如何将它集成到一个仪表板中？
-
是否有集成Dashboards的教程（kibana和graphitos / graph explorer / orion / pencil）？
提前致谢 .
1 回答
为什么statsd-graphite：
Statsd和Graphite可以帮助您可视化任何事物，而不仅仅是日志和系统命中注意力 . 使用statsd-graphite堆栈非常简单，可以测量悬停在站点左下方的用户数量超过10秒 .
由于没有涉及中间日志记录，因此从IO的角度来看，石墨提供的可扩展性是无与伦比的 . 还要考虑statsd会谈UDP的事实，因此每分钟收集300K指标是轻而易举的 .
您无需记录某些内容即可查看 .
积分：
如您共享的体系结构图中清楚地显示的那样，您可以过滤要显示的统计信息，将它们转发到statsd . 这与直接从logstash-elasticsearch可视化的kibana并行 . 如果您想通过Graphite查看Graphite和Kibana数据，那么对数据进行冗余是一种更简单的方法，因为webapp不会直接查询elasticsearch .
Vimeo的Graph Explorer是你可能想要研究的东西 . 它查询elasticsearch .
更新：
并不是说Logstash不会这样做，但它不是为那个角色“设计”的，而statsd等人则是 .
石墨中组织的固有方案是树状的，因此搜索不会/不能从不同的子树中得到结果 . 这使得它不适合进行跨维搜索 . 考虑到你想要的力量，GE是最简单的 .
图形资源管理器通过adding tags to the metrics解决此问题并将其与elasticsearch集成 . 那么通用电气实际上做的是 -
一次 - 它连接到您的Graphite前端，进行API调用以检索所有指标 .
然后将旧式proto 1指标（A.B.C）“转换”为基于标签的proto 2指标（host = A.app = B.username = C） .
然后将其导出到维护索引的ES .
当您查询GE前端时，它会连接到ES以了解您的需求 .
GE然后查询Graphite-API，并在GE前端提供结果 .
没有 .
这些是对可视化的表面优化 . 他们-
更改图形的外观 .
使查询API更容易 .
允许更好的监控流程 .
它们不会改变您存储或搜索信息的方式 . GE将自身'deeper'嵌入到度量标准数据中，因此与查询度量标准有着真正的优势 . （跨维搜索）
GE的公制导入插件远非完美 . 它成功地从我的1000个指标中导出了300个 . 渲染也更重，前端吃更多的NW（因为可恢复的，可缩放的功能） .
Grafana出局了 .