如何使用 SHOW STATS 命令和 _internal 数据库来监控 InfluxDB
作者 Philip O'Toole / 产品
2015年9月22日
导航到
InfluxDB 支持使用 统计 和 诊断 元查询,这允许开发人员和系统管理员更好地利用他们的 InfluxDB 系统,诊断问题,并解决问题。
本文概述了 InfluxDB 目前收集的一些统计信息和一些如何处理这些信息的建议。
谁在监视监视者?
InfluxDB 的一个常见用途是监控和分析 IT 基础设施。要成功运行 InfluxDB 系统,数据库本身也必须得到监控。命令 SHOW STATS
允许您做到这一点。 SHOW STATS
返回有关系统各个组件的信息,对于接收查询的节点。每个导出统计信息的模块都导出一个以模块命名的 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
能做的几个快速示例。请注意,根据启用的服务以及数据库中执行的代码路径,您可能还会看到来自其他组件的统计信息。
内部数据库
所有这些统计信息非常有用,但系统重启时会重置。如果我们想分析系统随时间的变化性能怎么办?当然,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的标签,因此分析特定节点总是可能的。下面是主机名为malthus
的节点上Graphite服务的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。