TiDB 多集群监控部署方案实战

作者： dba-kit 原文来源：https://tidb.net/blog/0c02aff3

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 很不友好是最难维护的，想想一下场景：

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

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

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

2.2. 复用 Altermanager、Grafana

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

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

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

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

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

2.3. 最终架构

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

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

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

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

4. 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

配置解释：

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

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

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

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

5. 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