logging - Kibana 3 里程碑 4 和 Graphite 集成

Question

我很难理解集成 Graphite 和 Kibana 3 来监控日志和系统生命力。我指的是 Log management system described here 中的图.

1. 考虑到 Kibana 3 Milestone 4 中的新功能，我们能否收集系统活力并将其直接存储到 Elasticsearch 中而不是 Graphite 中，并使用单个 Kibana 仪表板(在强调的分布式系统中实现什么可能是正确的选择性能和低内存占用)？
2. 当 kibana - Elasticsearch 组合现在支持计数和简单统计时，为什么我们必须使用 StatsD 和 Graphite？
3. 如果我们决定同时使用 Graphite 和 kibana，我们如何将其集成到一个仪表板中？
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 数据，那么使用数据冗余是一种更简单的方法，因为 web 应用程序不会直接查询 elasticsearch。

Vimeo 的 Graph Explorer是你可能想要研究的东西。它查询 elasticsearch。

---

更新:

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

I have been wondering if we have a simpler query language.

Graphite 的固有组织结构是树状的，因此搜索不会/不能从不同的子树中产生结果。这使得它不太适合跨维度搜索。 GE 是最简单的，只要你想要动力。

Graph Explorer's flow-

Graph Explorer 通过 adding tags to the metrics 解决了这个问题并将其与 elasticsearch 集成。所以 GE 实际上做的是——

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

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

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

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

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

Moreover, does graph explorer assume we are using diamond for collection?

没有。

How does it compare to pencil, orion and graphiti?

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

1. 更改图表的外观。

2. 使查询 API 更容易。

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

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

Heads up-

GE 的指标导入插件远非完美。它成功导入了我的 1000 个指标中的 300 个。渲染也更重，前端吃更多的 NW(因为可悬停、可缩放的特性)。

Update-

Grafana出来了。