关于tidb:技术分享-技术分享-Zabbix-监控-TiDB-二

5次阅读

共计 4486 个字符，预计需要花费 12 分钟才能阅读完成。

作者：胡呈清

爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95…，欢送探讨。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

如果要应用 Zabbix 监控应用 TiDB，需应用 HTTP agent，被动调用 TiDB 监控接口获取监控数据，而后配置数据预处理：抉择应用 Prometheus pattern 或者 Prometheus to JSON 办法，然而这两个性能是在 Zabbix4.2 中退出的，Zabbix4.0.x 没有这个性能（即便是最新的 zabbix4.0.35）：

所以在没法降级到 Zabbix5.4 时，咱们能够在大于 4.2 的版本上手工创立监控模板，以下演示环境为 Zabbix5.0.5。

在开始前，须要先理解 TiDB 的监控接口：https://docs.pingcap.com/zh/t…

示例：

curl http://127.0.0.1:10080/metrics > /tmp/tidb_metics

参考 TiDB 官网上的告警规定（https://docs.pingcap.com/zh/t…）中的第一条告警规定：

increase(tidb_session_schema_lease_error_total{type="outdated"}[15m]) > 0

这个是 prometheus 的语法，咱们只须要晓得 tidb_session_schema_lease_error_total 是 metrics name 就行，而后咱们去监控数据中找到这个 metric（TiDB 的不同版本 metric 可能不一样，示例中的 metric 在 4.0.10 中就没有，在 5.1 中有）：

[root@localhost tmp]# grep tidb_session_schema_lease_error_total /tmp/tidb_metics 
# HELP tidb_session_schema_lease_error_total Counter of schema lease error 
# TYPE tidb_session_schema_lease_error_total counter tidb_session_schema_lease_error_total{type="outdated"} 2

其数据格式为：

阐明

以“# HELP”结尾，是对这个 metric 的阐明

类型

以“# TYPE”结尾，示意这个 metric 的数据类型，一共有 4 种：

数据

这里要留神的就是上述示例中的“type”标签，有些 metric 会有多个标签，咱们能够依据标签取其中的几个（比方需要是计算所有 Select、Update、Insert 命令的总耗时）：

tidb_server_handle_query_duration_seconds_sum{sql_type="Begin"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Commit"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Delete"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Execute"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Insert"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Replace"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Rollback"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Select"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Set"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Show"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Update"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="Use"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="general"} 0
tidb_server_handle_query_duration_seconds_sum{sql_type="internal"} 12260.158577597258

接下来介绍如何在 Zabbix 中手工增加 TiDB 监控。

item 就是监控项，那咱们要监控 TiDB 的哪些指标呢？能够参考官网告警规定，须要告警的监控项肯定是最优先的。

创立 master item

参数如下图，红色标记是重点。这个 item 定义了调用 TiDB Server 的 metrics 接口获取到所有监控指标的数据：

留神取到的数据格式为 Text，须要在“Preprocession”(数据预处理) 中定义转化成 JSON 格局：

创立一般 item

因为 master item 获取的是所有 metrics，所以须要创立子 item 从 master item 中取出单个 metrics：

关键在于“Preprocession”(数据预处理) 中定义 JSONPath，如下图所示：

JSONPath 表达式：$[?(@.name=="tidb_session_schema_lease_error_total" && @.labels.type == "outdated")].value.first() 示意取 metric name 为 tidb_session_schema_lease_error_total 并且其 tpye 标签为 “outdated” 的值。留神：5.4 的模板中的这个表达式是谬误的，能够用 test 性能检测。
因为这个 metric 的类型是 Counter（累计值），所以用 ”Change per second” 办法获得其均匀每秒的增长值（留神：这是个平均值）。如果类型是 Gauge（瞬时值）就不须要这步解决了。

trigger 就是定义当指定 item 的值达到什么条件，就触发其状态变成异样。先参考 TiDB 官网告警规定的 Prometheus 语法：
increase(tidb_session_schema_lease_error_total{type="outdated"}[15m]) > 0

increase([15m]) 函数示意在 15 分钟内的增长值，整个表达式含意：为 15 分钟内的增长大于 0。因为咱们在 item 中定义的是 tidb_session_schema_lease_error_total 每秒增长量，所以当一段时间内均匀每秒增长量的最大值大于 0 时，阐明产生了 error，就须要触发告警，触发器表达式为：
{TiDB by HTTP:tidb.session_schema_lease_error.outdate.rate.max(15m)}>0

示例数据：

[
  {
    "name": "tidb_server_handle_query_duration_seconds_sum",
    "value": "100",
    "line_raw": "tidb_server_handle_query_duration_seconds_sum{sql_type=\"Begin\"} 0",
    "labels": {"sql_type": "Begin"},
    "type": "untyped"
  },
  {
    "name": "tidb_server_handle_query_duration_seconds_sum",
    "value": "50",
    "line_raw": "tidb_server_handle_query_duration_seconds_sum{sql_type=\"Commit\"} 0",
    "labels": {"sql_type": "Commit"},
    "type": "untyped"
  }
]

表达式：$[?(@.name=="tidb_server_handle_query_duration_seconds_sum")].value.sum()

含意：所有命令的总耗时

测试后果：150

表达式：$[?(@.name=="tidb_server_handle_query_duration_seconds_sum" && @.labels.sql_type=="Commit")].value.first()

含意：所有 Commit 命令的总耗时

测试后果：50

表达式：$[?(@.name=="tidb_server_handle_query_duration_seconds_sum" && @.labels.type =~ "Begin|Commit")].value.sum()

含意：所有 Begin、Commit 命令的总耗时（其余类型的不计算）

测试后果：150

文档：https://www.zabbix.com/docume…

基于其它监控项来创立可计算监控项，指定新创建的 item 为 “Calculated” 即可，以下示例先创立了两个 item：query_duration_sum、query_duration_count，两者相除失去 Query 的均匀响应工夫：

1. 内存使用量

表达式：
{TiDB by HTTP:tidb.heap_bytes.min(5m)}>{$TIDB.HEAP.USAGE.MAX.WARN}

含意：

tidb.heap_bytes 是 key 名，对应的是 TiDB 监控中的 go_memstats_heap_inuse_bytes 指标，这是个 Gauge 类型（即瞬时值）；
5 分钟内，应用的内存最小值超过指定阈值（也就是继续 5 分钟内，应用的内存都超过了阈值），就报警

2.99 响应工夫

如何计算 99% 的 SQL 的响应工夫？

TiDB 监控接口提供的是直方图数据，类型为 histogram，prometheus 能够用 histogram_quantile() 函数解决：
histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket[1m])) BY (le, instance)) > 1

然而 zabbix 解决不了，能够计算均匀响应工夫（用附录中的可计算 item 实现）。

正文完