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

原创
2023/12/29 00:00
阅读数 21

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

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

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

其中grafana_serversalertmanager_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 SidecarThanos 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准备的,截图如下: Pasted image 20231229200235.png 可以发现其用的label为tidb_cluster,而prometheus.yml上配置的是: external_labels: [cluster: 'perf-tidb1'],稍微改造一下就可以了,示意如下: Pasted image 20231229200709.png

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,就可以在一个面板看到不同集群的监控。 Pasted image 20231229204019.png

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
展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部