如何使用 SHOW STATS 命令和 _internal 数据库监控 InfluxDB
作者:Philip O'Toole / 产品
2015年9月22日
导航至
InfluxDB 支持统计信息和诊断信息元查询,这使开发者和系统管理员能够更好地利用其 InfluxDB 系统,诊断问题并排除故障。
本文概述了 InfluxDB 当前收集的一些统计信息和诊断信息,并提供了一些关于如何使用这些信息的建议。
谁来监控监控者?
InfluxDB 的一个常见用途是监控和分析 IT 基础设施。为了成功运行 InfluxDB 系统,必须监控数据库本身。 SHOW STATS
命令允许您做到这一点。SHOW STATS
返回关于系统各个组件的信息,针对接收查询的节点。每个导出统计信息的模块都导出一个名为该模块的 Measurement(度量),并且各种系列与该 Measurement 相关联。(Measurement 这一事实很重要,稍后将会看到。)
让我们看一下 runtime(运行时)统计信息,它捕获了关于 Go 运行时的详细信息。
> show stats
name: runtime
-------------
Alloc Frees HeapAlloc HeapIdle HeapInUse HeapObjects HeapReleased HeapSys Lookups Mallocs NumGC NumGoroutine PauseTotalNs Sys TotalAlloc
4056352 15134 4056352 1712128 4874240 7001 0 6586368 71 22135 4 51 1573952 10918136 13093576
在这种情况下,SHOW STATS
为您提供了 InfluxDB 系统在 Go 运行时内的内存使用情况的概览。许多 Go 开发者会认识到这些数字的重要性。
另一个关键统计信息是 httpd 模块
name: httpd
tags: bind=:8086
query_req query_resp_bytes req
--------- ---------------- ---
2 418 2
此输出显示自系统启动以来,此节点接收到的查询数量 (query_req
) - 在此示例中为 2 - 以及返回给客户端的字节数,在本例中为 418(此系统刚刚启动!)。
大多数输入,例如 Graphite 和 openTSDB,也都有详细的统计信息可用。这在与这些系统一起工作时特别有用。我们收到了很多关于这些输入性能的问题,因此这些统计信息可能非常有用。
以下是 Graphite 输入的示例统计信息
name: graphite
tags: bind=:2003, proto=tcp
batches_tx bytes_rx connections_active connections_handled points_rx points_tx
---------- -------- ------------------ ------------------- --------- ---------
62 1658490 6 6 69006 62000
这显示了 Graphite 服务在端口 2003 上接收到的点数 (points_rx
),用于 TCP 协议。它还显示了发送到数据库的点数 (points_tx
)。如果您注意到 points_rx
大于 points_tx
。这表明 Graphite 输入在内部缓冲点,因为它将写入批处理到数据库中以实现最大吞吐量。
这些只是 SHOW STATS
可以做到的一些快速示例。请记住,根据启用的服务以及数据库中执行的代码路径,您可能会看到来自其他组件的统计信息。
internal(内部)数据库
所有这些统计信息都非常有用,但在系统重启时会重置。如果我们想分析系统随时间的性能怎么办?当然,InfluxDB 是一个时间序列数据库,专门为存储此类数据而构建。因此,系统定期将所有统计数据写入一个名为 _internal
的特殊数据库,这使您可以使用 InfluxQL 的全部功能来分析系统本身。
一些示例可能会有所帮助。
如果您对 InfluxDB 如何使用 Go 堆有疑问,则很容易查看使用情况随时间的变化。例如,使用 influx
CLI,发出以下查询以每 10 秒查看一次 Go 堆使用情况。
> USE _internal
Using database _internal
> SHOW MEASUREMENTS
name: measurements
------------------
name
graphite
httpd
runtime
shard
write
> SELECT HeapAlloc FROM runtime LIMIT 5
name: runtime
-------------
time HeapAlloc
2015-09-18T18:40:04.199587653Z 548536
2015-09-18T18:40:14.199761008Z 3895536
2015-09-18T18:40:24.199791989Z 2057504
2015-09-18T18:40:34.19971719Z 2111680
2015-09-18T18:40:44.199490569Z 2169848
更好的是,当与像 Chronograf 这样的工具结合使用时,您可以可视化所有这些数据。
下一个查询示例,也使用 Chronograf 可视化,显示了 Go 运行时垃圾回收 (GC) 总暂停时间的 derivative
(导数)查询。由于此图显示了变化率,因此图中的峰值显示了何时发生 GC 暂停。
集群级别统计信息
由于集群中的每个节点都将这些统计信息写入 _internal
数据库,因此针对 _internal
的查询会返回整个集群的数据,这可能非常有用。但是,所有数据都标有主机名和节点 ID,因此始终可以分析特定节点。下面显示的是 Graphite 服务在主机名为 malthus
的节点上的 points_rx
。
> SHOW TAG VALUES WITH key=hostname
name: hostnameTagValues
---------------------
hostname
malthus
> SELECT points_rx FROM graphite WHERE hostname='malthus' LIMIT 5
name: graphite
--------------
time points_rx
2015-09-18T18:40:54.199425753Z 141001
2015-09-18T18:41:04.19947468Z 315608
2015-09-18T18:41:14.1993757Z 476001
2015-09-18T18:41:24.199438213Z 641001
2015-09-18T18:41:34.199454694Z 802001
但请记住,SHOW STATS
和 SHOW DIAGNOSTICS
命令始终只返回 执行查询的节点 的数据。
Expvar 支持
如果您希望使用外部工具监控 InfluxDB,则所有统计数据都以标准 expvar 格式提供。此信息可在端点 /debug/vars
处获得。
诊断信息
诊断信息在 InfluxDB 系统中以略有不同的方式处理。它主要是关于系统的信息,不一定是数字格式。重要的是要注意,诊断信息不存储在 _internal
数据库中。
示例数据是您的 InfluxDB 的构建版本及其运行时间。此信息对 InfluxDB 支持特别有用,因此在您提交支持工单或 GitHub 问题时,请务必包含此查询的输出。
示例输出如下所示。
> SHOW DIAGNOSTICS
name: system
------------
PID currentTime started uptime
7299 2015-09-18T20:32:22.219545782Z 2015-09-18T19:54:04.069260449Z 38m18.150285438s
name: build
-----------
Branch Commit Version
master d81618c57fae135d9b1c1a8fb3403722ceb29354 0.9.4
name: runtime
-------------
GOARCH GOMAXPROCS GOOS version
amd64 8 linux go1.5
name: network
-------------
hostname
malthus
更多内容即将推出
与往常一样,我们鼓励开源开发者在他们贡献的任何代码中添加统计信息和诊断信息,如果这有意义的话。我们希望您发现这些信息在您使用 InfluxDB 时很有用。如果您有任何问题或疑虑,请加入我们的 社区 Slack。