logging - Kibana 3 Milestone 4 和 Graphite 集成

Question

我很难理解 Graphite 和 Kibana 3 的集成来监控日志和系统生命体征。我指的是此处描述的日志管理系统中的图。

1. 考虑到 Kibana 3 Milestone 4 中的新功能，我们是否可以收集系统生命体征并将其直接存储到弹性搜索中而不是石墨并使用单个 kibana 仪表板（在强调性能和低性能的分布式系统中实施什么可能是正确的选择？内存脚印）？
2. 当 kibana - Elasticsearch 组合现在支持计数和简单统计时，为什么我们必须使用 StatsD 和石墨？
3. 如果我们决定同时使用 Graphite 和 kibana，我们如何将其集成到单个 Dashboard 中？
4. 是否有集成仪表板的教程（kibana 和 graphitos/graph explorer/orion/pencil）？

提前致谢。

Answer 1

为什么选择 statsd-graphite：

1. Statsd 和 Graphite 可以帮助您可视化任何内容，而不仅仅是日志和系统生命体征。使用 statsd-graphite 堆栈非常简单，可以测量在您的网站左下角悬停超过 10 秒的用户数。

2. 由于不涉及中间日志记录，因此从 IO 的角度来看，graphite 提供的可扩展性是无与伦比的。还要考虑 statsd 与 UDP 通信的事实，因此每分钟收集 300K 指标是轻而易举的事。

3. 你不必为了看到它而记录一些东西。

一体化：

正如您共享的架构图中清楚地显示的那样，您可以过滤要可视化的统计信息，将它们转发到 statsd。这与直接从 logstash-elasticsearch 进行可视化的 kibana并行。如果您想通过 Graphite 同时查看 Graphite 和 Kibana 数据，那么使用数据冗余是一种更简单的方法，因为 webapp 不会直接查询 elasticsearch。

Vimeo 的图形资源管理器是您可能想要研究的东西。它查询弹性搜索。

---

更新：

并不是说 Logstash 不这样做，而是它不是为该角色“设计”的，而 statsd 等人是。

我一直想知道我们是否有更简单的查询语言。

石墨的固有组织方案是树状的，因此搜索不会/不能产生来自不同子树的结果。这使得它不太适合跨维度搜索。GE 是最简单的，只要你想要权力。

Graph Explorer 的流程——

Graph Explorer 通过向指标添加标签并将其与弹性搜索集成来解决此问题。所以通用电气实际上做的是——

1. 一次 - 它连接到您的 Graphite 前端，进行 API 调用以检索所有指标。

2. 然后，它将旧样式的 proto 1 指标 (ABC) “转换”为基于标签的 proto 2 指标 (host=A.app=B.username=C)。

3. 然后将其导出到维护索引的 ES。

4. 当你查询 GE 前端时，它会连接到 ES 以了解你想要什么。

5. GE 然后查询 Graphite-API，并在 GE 前端传递结果。

此外，图形浏览器是否假设我们使用钻石进行收集？

不。

它与铅笔、猎户座和石墨相比如何？

这些是对可视化的表面优化。他们-

1. 改变图表的外观和感觉。

2. 使查询 API 更容易。

3. 允许更好的监控流程。

他们不会改变您存储或搜索信息的方式。GE 将自己“更深入”地嵌入到指标数据中，因此在查询指标方面具有真正的优势。（跨维搜索）

小心-

GE 的公制导入插件远非完美。它成功地从我的 1000 个指标中导入了 300 个。它的渲染也更重，并且前端消耗了更多的 NW（因为可悬停、可缩放的功能）。

更新-

格拉法纳出局了。