作者： dba-kit
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