使用 Prometheus + Grafana 打造 TiDB 监控整合方案

从本文中，你将将了解到：

• 如何将不同的 TiDB 集群 Prometheus 监控平台整合到同一 Prometheus 平台中。

• 如何通过 Grafana 查看 Prometheus 中的 metric。

• 如何将不同集群的 cluster 标签注入到 Grafana dashboard 中。

• 如何通过 Grafana HTTP API 批量将报表导入到 Grafana 中。

• 如何解决大量指标数据造成的 Prometheus 性能问题。

• 如何将 Prometheus 中的数据导入到关系型数据库中进行查询或指标分析。

• 如何实现 Prometheus 的高可用和高租户。

本文的思路导读：

• 我想做什么：将每个集群独立的 Prometheus + Grafana 整合到统一的平台，单一入口进行查询。

• Prometheus如何整合：使用独立的 Prometheus 拉取不同集群的 metric，通过 label 进行区分。

• Grafana 如何整合：需要将每一个 expr 都推入集群的标签信息加以隔离，生成新的报表，使用 Grafana HTTP API 批量导入报表。

• 整合后可能带来的风险：Prometheus 数据量炸库，性能缓慢。

• 怎么办：拆库！为什么刚合并的库要拆分？

• 拆分的目标：Prometheus 水平扩展，数据集中存储远程库。

• 数据集中存储方案：使用 prometheus-postgresql-adapter + TimescaleDB 进行数据存储。

• 数据集中存储有什么问题：Dashboard 的 expr 需要从 Timescale DB 中读取，原来的基于 PromSQL 的 expr 无法使用。

• 如何解决 SQL 转换 PromSQL 的问题：在 Timescale 上再接一层 Prometheus 进行转换。

• Prometheus 的水平扩展和多租户方案：Thanos。

有一些话要提前说一下：

• 作为一个长期奋斗于一线，到了二线三线也放不下一线的 DBA，我最关心三件事情（排名有先后）：

• 饭碗拿的好：正确性，数据不能少。

• 我想睡得早：稳定性，晚上不报警。

• 安心去养老：查询是产品的问题，关我 DBA 什么事情。

• 为此，作为一位非著名 DBA，我整理了一下 TiDB 监控整合方案的思路

• 本文是思路，不敢叫做方案。

• 本息记录了，我拿出一个方案，再推翻这个方案的迭代过程。

• 每个方案都有自己的独特性，所以没有最好的方案，只有最适用的方案。

[root@r30 .tiup]# cat /etc/redhat-release
CentOS Stream release 8
[root@r30 .tiup]# uname -r
4.18.0-257.el8.x86_64

作为实验环境，我们部署了两套 TiDB 集群，tidb-c1-v409，tidb-c2-v409。

在一台独立的机器上，我通过 TiUP 部署了一套集群 tidb-monitor 系统后，只保留 Grafana 与 Prometheus 组件。删除了其他的 TiDB 组件。这套 tidb-monitor 集群是为了模拟我们已有的监控平台，将 tidb-c1-v409 与 tidb-c2-v409 的监控迁移到 tidb-monitor 上。

Prometheus 是一个拥有多维度数据模型的、灵活的查询语句的时序数据库。

Prometheus 作为热门的开源项目，拥有活跃的社区及众多的成功案例。

Prometheus 提供了多个组件供用户使用。目前，TiDB 使用了以下组件：

• Prometheus Server：用于收集和存储时间序列数据。

• Client 代码库：用于定制程序中需要的 Metric。

• Alertmanager：用于实现报警机制。

Grafana 是一个开源的 metric 分析及可视化系统。

TiDB 使用 Grafana 来展示 TiDB 集群各组件的相关监控，监控项分组如下图所示：

随着集群数量的增加，部分用户可能存在以下的需求：

• 多套 TiDB 集群无法共享一套监控集群

• Prometheus 本身不具有高可用性随着数据量的增长

• Prometheus 的查询速度会降低

于此，我们考虑是否可以整合不同集群的 Prometheus 和 Grafana，做到多集群共用一套建监控系统。

TiDB 使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案，使用 Grafana 作为可视化组件进行信息的展示。Prometheus 狭义上是软件本身，即 prometheus server，广义上是基于 prometheus server 为核心的各类软件工具的生态。除 prometheus server 和 grafana 外，Prometheus 生态常用的组件还有 alertmanager、pushgateway 和非常丰富的各类 exporters。prometheus server 自身是一个时序数据库，相比使用 MySQL 做为底层存储的 zabbix 监控，拥有非常高效的插入和查询性能，同时数据存储占用的空间也非常小。如果要使用 prometheus server 接收推送的信息，数据源和 prometheus server 中间需要使用 pushgateway。

Prometheus 监控生态非常完善，能监控的对象非常丰富。详细的 exporter 支持对象可参考官方介绍 exporters 列表 。Prometheus 可以监控的对象远不止官方 exporters 列表中的产品，有些产品原生支持不在上面列表，如 TiDB；有些可以通过标准的 exporter 来监控一类产品，如 snmp_exporter; 还有些可以通过自己写个简单的脚本往 pushgateway 推送；如果有一定开发能力，还可以通过自己写 exporter 来解决。同时有些产品随着版本的更新，不需要上面列表中的 exporter 就可以支持，比如 ceph。随着容器和 kurbernetes 的不断落地，以及更多的软件原生支持 Prometheus，相信很快 Prometheus 会成为监控领域的领军产品。

Prometheus 的架构图如下：

Prometheus 生态中 prometheus server 软件用于监控信息的存储、检索，以及告警消息的推送，是 Prometheus 生态最核心的部分。Alertmanger 负责接收 prometheus server 推送的告警，并将告警经过分组、去重等处理后，按告警标签内容路由，通过邮件、短信、企业微信、钉钉、webhook 等发送给接收者。大部分软件在用 Prometheus 作为监控时还需要部署一个 exporter 做为 agent 来采集数据，但是有部分软件原生支持 Prometheus，比如 TiDB 的组件，在不用部署 exporter 的情况下就可以直接采集监控数据。

PromQL 是 Prometheus 数据查询语言，用户可以通过 prometheus server 的 web UI，在浏览器上直接编写 PromQL 来检索监控信息。也可以将 PromQL 固化到 grafana 的报表中做动态的展示，另外用户还可以通过 API 接口做更丰富的自定义功能。Prometheus 除了可以采集静态的 exporters 之外，还可要通过 service discovery 的方式监控各种动态的目标，如 kubernetes 的 node,pod,service 等。除 exporter 和 service discovery 之外，用户还可以写脚本做一些自定义的信息采集，然后通过 push 的方式推送到 pushgateway，pushgateway 对于 prometheus server 来说就是一个特殊的 exporter，prometheus server 可以像抓取其他 exporters 一样抓取 pushgateway 的信息。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/