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