TiDB 多集群监控部署实战经验分享

1. 单集群部署可选配置项

TiDB在部署时候可以选择部署监控系统，可选配置有：

monitoring_servers：包含Prometheus和NgMonitoring(用于支持 TiDB Dashboard 中持续性能分析和 Top SQL 功能)，详细见：官方文档-monitoring_servers

grafana_servers：部署Grafana的相关参数，详细见：官方文档-grafana_servers

alertmanager_servers：部署Alertmanager的相关参数，详细见：官方文档-alertmanager_servers

其中grafana_servers和alertmanager_servers配置比较简单，如果当前公司没有现成的组件，可以直接看TiUP的文档部署。不过具体的配置设置，还是得看Grafana/Alertmanager自己的官方文档，TiDB 并不会做额外定制。而TiDB会根据集群现状自动生成Prometheus的配置文件，这样在扩容后自动采集新扩容节点监控指标，也可以在缩容后将下线节点的采集配置删除。因此monitoring_servers的配置就会显得略显复杂，下面我会详细介绍一下我们线上的配置。

1.1 monitoring_servers配置

在搜索如何更好使用 TiDB 告警系统时，在官方文档中找到了一个页面：自定义监控配置项，发现在文档里，多了AdditionalScrapeConf这个配置项。问了确认是否还存在其他隐藏参数，我翻了下TiUP 的源代码，还发现了其他三个隐藏参数，分别是：

pushgateway_addrs：支持自己部署 pushgateway，自定义上传一些自助监控指标

scrape_interval：抓取监控指标的间隔，默认是15s。如果想缩小间隔增加告警的灵敏度，可以修改这个参数。

scrape_timeout：抓取超时时间，一般保持默认即可。

支持的变量有：

type PrometheusSpec struct { // 此处忽略了一些通用参数，只保留和Prometheus相关的可配置项RemoteConfig Remote`yaml:"remote_config,omitempty" validate:"remote_config:ignore"` ExternalAlertmanagers []ExternalAlertmanager `yaml:"external_alertmanagers" validate:"external_alertmanagers:ignore"` PushgatewayAddrs []string `yaml:"pushgateway_addrs,omitempty" validate:"pushgateway_addrs:ignore"` Retention string `yaml:"storage_retention,omitempty" validate:"storage_retention:editable"` RuleDir string `yaml:"rule_dir,omitempty" validate:"rule_dir:editable"` AdditionalScrapeConf map[string]any `yaml:"additional_scrape_conf,omitempty" validate:"additional_scrape_conf:ignore"` ScrapeInterval string `yaml:"scrape_interval,omitempty" validate:"scrape_interval:editable"` ScrapeTimeout string `yaml:"scrape_timeout,omitempty" validate:"scrape_timeout:editable"` }

2. 多个TiDB集群监控方案

2.1. 最原始模式

如图所示，每个集群都有自己的 Prometheus、Grafana、Altermanager，这种架构部署简单，适合每个集群是就是一个业务，每个业务都有自己的域名来访问自己集群的Grafana，Altermanager也可以根据业务来自己设置告警接收人和通知方式。

不过这种方式，对我们DBA很不友好是最难维护的，想想一下场景：

如果DBA组内人员有变动，需要所有集群都修改一下Altermanager，很容易出现漏配、错配的情况。

如果要做巡检，需要打开不同的Grafana页面，没有统一的视图。

每套TiDB集群都有自己的监控资源，存在较大的资源浪费，还没办法和Service告警放在一起展示。

2.2. 复用Altermanager、Grafana

如图所示，这种架构其实是通过external_alertmanagers方式，将所有集群Prometheus的告警都通过统一的Altermanager来发送，并使用公司统一的Grafana入口来展示TiDB监控信息。优缺点有：

将告警接受人和webhook配置收敛，简化了维护难度。

虽然复用了Grafana可以和Service的面板放在一起展示，但是因为每个集群都有自己的Prometheus，所以每创建一个集群都需要在Grafana里创建一个新文件夹，并逐个导入现有的dashboard。(每次导入都得手动改datasource和uid，其实也挺麻烦的)

集群的Prometheus既负责采集，还要兼顾通过Grafana的查询需求。如果很多人在使用或者某个人查询时间范围太大，把Prometheus搞OOM了，就会导致告警发不出来。

由于Prometheus要承担查询需求，所以CPU、内存、磁盘的资源都不能给的太小，必须给一个较高的资源。

2.3. 最终架构

如图所示，这种是我们公司现在的架构：

TiDB集群的Prometheus只负责指标采集并通过remote_write将指标上传到公司的 proxy-prometheus节点，本身不承担用户查询需求。所以只需要保留1天的监控数据，其配置也可以给的很低。

Proxy-prometheus节点上部署了 Thanos Sidecar，Thanos Sidecar会周期将数据上传到 S3 中，Proxy-prometheus也只会保留最近1天的数据。注意：告警规则也在Proxy-prometheus上，所以不同集群只需要一套告警规则即可。

Thanos-query组件，会同时从直接从proxy-prometheus和 OSS 中读取历史监控指标，返回的是聚合后的结果。

Grafana只会从Thanos-query组件查询，即便出现性能问题也不会影响TiDB集群的Prometheus的告警采集。

3. 集群配置修改

3.1 TiUP配置修改

# TiDB集群Prometheus配置： remote_config: remote_write: - url: http://prometheus-proxy.XXXXXX.com/api/v1/write storage_retention: 1d additional_scrape_conf: relabel_configs: - source_labels: - __address__ target_label: target - regex: 192.168.11.11:(.*) replacement: prod-tipd-e001:$1 source_labels: - __address__ target_label: instance - source_labels: - instance target_label: host ## Proxy-Prometheus节点配置 external_alertmanagers: - host: alertmanager.XXXXXX.com web_port: 80 storage_retention: 1d rule_dir: /root/deploy-config/tidb-config/rules

配置解释：

remote_config：通过remote_write将指标上传到公司的 proxy-prometheus节点，该节点上部署了 Thanos会周期将数据上传到 OSS 中，配套的Thanos-query 组件可以直接从 OSS 中读取历史监控指标。

external_alertmanagers：也是直接使用公司的alertmanager节点，这个是为了避免在每个集群都得维护一份分发规则。

storage_retention：因为已经将指标写入到远端，TiDB 的prometheus可以只保持1天的数据。

rule_dir： 将告警规则维护在本地，方便根据实际情况修改告警阈值。

additional_scrape_conf：增加了relabel_configs配置，我这里是为了在Grafana Dashboard中将 IP 替换为有业务含义的名字。

注意： additional_scrape_conf中的配置，最终都会被渲染到scrape_configs下的所有job中，所以必须慎重考虑，看是不是会影响正常的监控配置!!!

上面配置中我们添加了relabel_configs，这会替换所有的job 中的relabel_configs内容，也就导致tidb_port_probe失效了。不过这个只影响集群内各节点之间的探活，并不会影响正常的业务指标采集，也不会影响各节点直接上报的健康监测指标，所以经过评估后，我们还是设置了relabel_configs。

按照上述配置后，在Grafana中查询到的metrics例子为：

pd_cluster_status{cluster="perf-tidb1", host="prod-tipd-e001:2379", instance="prod-tipd-e001:2379", job="pd", monitor="prometheus", slave="prometheus-proxy", target="192.168.11.11:2379", type="leader_count"}

3.2. 所有数据都汇总到了proxy-prometheus，如何区分是哪个TiDB集群的指标呢？

其实看上述的metric也能发现，在里边多了一个cluster="perf-tidb1"这个label。这是因为在TiDB集群的Prometheus的prometheus.yml配置中，都主动设置了external_labels，在经过remote_write发给proxy-prometheus或者发送给altermanager时候，都会主动增加cluster: perf-tidb1这个label。这样只要TiDB集群名字不同，就可以根据cluster这个label来区分不同集群了。

--- global: scrape_interval: 15s # By default, scrape targets every 15 seconds. evaluation_interval: 15s # By default, scrape targets every 15 seconds. external_labels: cluster: perf-tidb1 monitor: "prometheus"

3.3. Grafana适配

在写文档时候突然想到，在proxy-prometheus配一个relable规则，将cluster这个label名字直接改写成tidb_cluster，这样可能更方便，就不用改造Grafana了，大家有兴趣可以尝试一下。

1. 参数修改 不过默认的Grafana的dashboard的配置确实有问题，需要更新一下变量。因为原始的变量是为tidb on k8s准备的，截图如下： 可以发现其用的label为tidb_cluster，而prometheus.yml上配置的是： external_labels: [cluster: perf-tidb1]，稍微改造一下就可以了，示意如下：

2. 表达式修改 和参数类型，表达式也要改一下，原始的表达式里用的label也是tidb_cluster：

sum(rate(tidb_executor_statement_total{k8s_cluster="$k8s_cluster", tidb_cluster="$tidb_cluster"}[1m])) by (type)

也需要对json文件做全局替换，将tidb_cluster=替换为cluster=，变成

sum(rate(tidb_executor_statement_total{k8s_cluster="$k8s_cluster", cluster="$tidb_cluster"}[1m])) by (type)

3. 最终效果

虽然看起来操作有点儿复杂，但是只需要第一次导入时候配置好，后面不过新增几个TiDB集群都不需要额外设置。只需要参数选择不同的tidb_cluster，就可以在一个面板看到不同集群的监控。

3.4. 告警规则适配

将告警规则维护在Proxy-prometheus中，需要手动改一下模板。原始的告警模板如下：

- alert: TiKV_node_restart expr: changes(process_start_time_seconds{job="tikv"}[5m]) > 0 for: 1m labels: env: perf-tidb1 level: warning expr: changes(process_start_time_seconds{job="tikv"}[5m]) > 0 annotations: description: cluster: perf-tidb1, instance: {{ $labels.instance }}, values:{{ $value }} value: {{ $value }} summary: TiKV server has been restarted

可以看到里边有硬编码集群名字：perf-tidb1，需要将其全局替换为{{ $cluster }}，最终告警规则应该为：

- alert: TiKV_node_restart expr: changes(process_start_time_seconds{job="tikv"}[5m]) > 0 for: 1m labels: env: "{{ $cluster }}" level: warning expr: changes(process_start_time_seconds{job="tikv"}[5m]) > 0 annotations: description: cluster: {{ $cluster }}, instance: {{ $labels.instance }}, values:{{ $value }} value: {{ $value }} summary: TiKV server has been restarted