我在理解 Graphite 和 Kibana 3 的集成以监控日志和系统生命体征时遇到了困难。我指的是Log management system described here中的图。
提前致谢。
【问题讨论】：
标签： logging elasticsearch graphite statsd kibana
为什么选择 statsd-graphite：
Statsd 和 Graphite 可以帮助您可视化任何内容，而不仅仅是日志和系统生命线。使用 statsd-graphite 堆栈非常简单，可以测量在您网站左下角停留超过 10 秒的用户数。
由于不涉及中间日志记录，因此从 IO 的角度来看，石墨提供的可扩展性是无与伦比的。还要考虑 statsd 与 UDP 通信的事实，因此每分钟收集 300K 指标是轻而易举的事。
您不必必须登录才能看到它。
整合：
正如您共享的架构图中清楚显示的那样，您可以过滤您想要可视化的统计信息，将它们转发到 statsd。这与 kibana 直接从 logstash-elasticsearch 可视化并行。如果您想通过 Graphite 同时查看 Graphite 和 Kibana 数据，那么使用数据冗余是一种更简单的方法，因为 web 应用程序不会直接查询 elasticsearch。
Vimeo 的Graph Explorer 是您可能想要查看的内容。它查询 elasticsearch。
更新：
并不是说 Logstash 不这样做，而是它不是为该角色“设计”的，而 statsd 等人是。
我一直想知道我们是否有更简单的查询语言。
graphite 中固有的组织结构是树状的，因此搜索不会/不能产生来自不同子树的结果。这使得它不太适合跨维度搜索。 GE 是最简单的，只要你想要权力。
Graph Explorer 的流程-
Graph Explorer 通过adding tags to the metrics 解决了这个问题，并将其与elasticsearch 集成。所以GE实际上做的是-
一次 - 它连接到您的 Graphite 前端，进行 API 调用以检索所有指标。
然后它将旧样式的 proto 1 指标 (A.B.C) “转换”为基于标签的 proto 2 指标 (host=A.app=B.username=C)。
然后将其导出到维护索引的 ES。
当您查询 GE 前端时，它会连接到 ES 以了解您想要什么。
GE 然后查询 Graphite-API，并将结果传递到 GE 前端。
此外，图形浏览器是否假设我们使用钻石进行收集？
没有。
它与铅笔、猎户座和石墨相比如何？
这些是对可视化的表面优化。他们——
更改图表的外观。
使查询 API 更容易。
允许更好的监控流程。
它们不会改变您存储或搜索信息的方式。 GE 将自己“更深入”地嵌入到指标数据中，因此在您查询指标的方式上具有真正的优势。 （跨维搜索）
注意——
GE 的指标导入插件远非完美。它成功地从我的 1000 个指标中导入了 300 个。它的渲染也更重，并且前端消耗了更多的 NW（因为可悬停、可缩放的功能）。
更新-
Grafana 不在。
【讨论】：