关于prometheus:一言难尽的Prometheus监控实践

39次阅读

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

说到 TiDB 的监控，大家第一工夫想到的就是 Prometheus 和 Grafana，这两个曾经是十分成熟的监控产品了，置信大家都有肯定的理解。那么这里对于 Prometheus 和 Grafana 不做过多的介绍，大略就是 Prometheus 会收集 TiDB 集群信息，Grafana 会调用这些信息生成可视化图标来进行展现。

而作为一名 DBA，为 TiDB 集群保驾护航之时，就少不了这两大工具，无论是日常巡检还是问题排查，咱们都须要关上 Grafana 看看集群状态，钻研各种指标，一一排查问题所在。

本文次要介绍一次理论我的项目中的 Prometheus 应用和踩的一些坑，那是真的是坑！如果你尝试对 TiDB 的 Prometheus 进自定义开发或是对接其余监控告警零碎等，那么读完这篇文章会对你有很大的帮忙！

首先谈谈我的项目背景，这次我的项目次要是搭建了一套 TiDB 的集群，节点十分多，而后对于 TiDB 集群的监控，公司有本人的要求，因为整个公司不止有一套 TiDB 集群，还有其余的 MySQL，Oracle 集群，为了不便公司的数据库治理，对于所有的数据库集群的监控和告警都心愿集成到同一个监控平台和告警平台。

简略的说就是开发了一套自有的监控和告警平台，来治理所有的数据库集群，那么对于 TiDB 集群，咱们的设计是，依然应用 TiDB 自带的 Prometheus 作为集群信息的收集者，而后在自有的监控告警平台上，通过应用 PQL 来查问 Prometheus 的数据，进行展现和对接到相应的告警零碎。你能够简略了解成从新开发了一个 Grafana 和 AlertManage。

TiDB 的 Prometheus 自身就自带一系列告警规定，这些告警规定根本就涵盖了 TiDB 集群的方方面面，所以咱们能够将这些告警规定间接搬过去。在 Prometheus 的部署目录，conf 文件上面能够找到。

在这些规定中，咱们能够提取出本人想要的一些规定集成到咱们本人的平台上，具体的集成办法能够参考一下：

首先到 rule.yaml 中找到本人想要集成监控告警项（比方 TiDB_server_panic_total，含意是 TiDB Server 呈现 panic 谬误超过一次则告警）
获取到 PQL，也就是 Expr 前面的这一段:，表达式非常容易了解，在 5 分钟内，如果 tidb 过程的启动工夫呈现变动，就代表 TiDB 服务重启过。
拜访 Prometheus 的 Api，通过 PQL 获取到数据，拜访形式就是 http://prometheus_address/api…
```
response = requests.get('http://%s/api/v1/query' % prometheus_address, params={'query': query})
```
获取到的查问后果后，就能够自行对后果进行解决，解决后输入到本人的监控告警平台下面。
对于 PQL 能够通过 http://prometheus_address/graph 先进行调试，对于 PQL 的语法也比较简单，只有晓得相应的 TiDB 指标和 PQL 的根本函数，就能够轻松的查问想要的后果。如果你感觉比拟麻烦，我倡议还是间接应用 rule.yaml 外面的 expr 的表达式，而后做一些小的批改就能满足绝大部分场景。

将 Prometheus 集成到自定义监控告警零碎大略就这么简略，获取后果后如何施展，就看大家本人的业务逻辑和设计了。

其实整个过程实现难度并不大，最大的难度，可能也只是在于你怎么解决从 Prometheus 获取到的数据。然而就这么简略的过程中，你也会遇到大量的坑去踩，坑的次要起源在于文档和版本。

我大抵形容一下：
咱们都晓得 TiDB 的版本更新是十分快的，所以对于 TiDB 的一些监控指标会随着版本发生变化，然而，TiDB 版本的更新速度和监控规定相干代码的跟新速度是不一样的，这里就呈现了两个变动因素，这个时候，咱们就须要查问各种文档，来进行对立，比方 TiDB 集群报警规定 | PingCAP Docs，问题又来了，TiDB 告警的文档更新的更慢，并且存在一些问题，这个时候你是不是就傻眼了？

当有三个因素都在变动的时候，想要确认某一件事件堪称是纠结万分，例如我举一个列子
tikv_batch_request_snapshot_nums 这个指标。

在文档中，这个指标意思是某个 TiKV 的 Coprocessor CPU 使用率超过了 90%，然而当你如果去掉超过 90% 的条件，单纯想要获取到 Coprocessor CPU 使用率的时候，你会发现 PQL 无奈从 Prometheus 中查问到任何的数据。

起因很简略，因为该 PQL 中 tikv_thread_cpu_seconds_total 这个指标外面基本就没有 name 为 cop 结尾的，也就是你无奈通过这个指标获取到 Coprocessor 的 CPU 使用率，而且不仅仅是文档，就连 Prometheus 外面 rule.yaml 也呈现了同样的谬误，所以在某些版本 TiDB 集群里的 Grafana 中你会发现你的 Coprocessor CPU 面板是没有数据的，如下：

那么根本原因是什么？我剖析的是因为在 TiDB 新版本中，引入了 UnifyReadPool 的概念，也就是将 Coprocessor 线程池与 Storage Read Pool 合并起来，那么 Coprocessor CPU 的使用率指标也就同样放到了 UnifyReadPool 外面去了，不在做独自的监控指标。
当然，有问题的监控指标还有很多，比方一些弃用了的指标，还有一些改名了的指标，合并或是拆解的指标，大家在应用的过程中，肯定要多进行测试，不然到时候集群出了问题，监控和告警没反馈那就很危险了。

因为篇幅无限，这里就不把那些有问题的中央一一出现了，这篇文章次要是记录一次 TiDB 集群监控告警自定义设计的我的项目实际，帮忙大家更好的把握和应用 TiDB 的 Prometheus，其中也是遇到了一些坑，心愿拿进去和大家分享，揭示大家在应用过程中留神一下。
踩了这么多坑，就会发现，TiDB 和其文档尽管当初曾经是相当弱小了，但却仍然存在一些大大小小的问题，作为社区的一员，也是会常常遇到这些问题。而 TiDB 作为一个开源我的项目，咱们享受开源福利的同时，其实也能够为其尽一份力，当咱们发现这些问题的时候，就能够去 Github 仓库提交一个小小的 PR，帮忙其欠缺。
之前也是发现了 Prometheus 的指标 node_cpu 在前面更新变成了 node_cpu_seconds_total，而文档还没有更新，我就提了一个 PR 到 PingCAP 的 doc 仓库，还取得了一个 Contributor 的徽章，十分滴炫酷。

正文完