核心要点
- TiDB 多集群监控的核心矛盾，是业务物理隔离导致集群数量增加，而每套集群自带 Grafana 和 Dashboard 分散在不同入口。
- 本篇介绍“初章”：先完成夜莺监控工具安装、业务组设计、数据源接入、告警规则和飞书通知模板。
- 夜莺的价值在于兼容 Prometheus、Zabbix、ES 等数据源接口，可以把多套 TiDB 集群的 Prometheus 数据统一纳入监控和告警治理。
- 业务组、团队、角色和数据源命名需要先设计清楚，否则后续几十套集群的告警规则和接收组会难以维护。
- 该实践适合已有多套 TiDB 集群、需要统一告警和巡检入口的 DBA 或平台运维团队。
实施路径总览
| 步骤 | 目标 | 原文实践 |
|---|---|---|
| 选择融合工具 | 降低多集群监控和告警管理成本 | 基于开源、成本和多数据源兼容性选择夜莺 |
| 安装与底层存储适配 | 满足 XC 项目要求 | 将监控底层存储 MySQL 替换为 TiDB，Redis 替换为某国产中间件 |
| 设计业务组和角色 | 让 DBA 与业务人员按职责查看告警 | 设计 LDAP 用户、机器人 token、团队、业务组和角色 |
| 接入数据源 | 将每套 TiDB Prometheus 纳入统一平台 | 按部门、中间件、业务系统、环境和 IP 命名 |
| 配置告警规则和模板 | 实现飞书自动告警 | 规范规则名称、备注、数据源、接收组和通知模板 |
背景
随着公司XC改造步伐的前进，越来越多的业务选择 TiDB，由于各个业务之间需要物理隔离，避免不了的 TiDB 集群数量越来越多。虽然每套 TiDB 集群均有两个详细的监控 Dashboard、Grafana，但对于运维来说几十套集群的监控、告警、巡检均需消耗巨大的精力。
“融合工具” - 拥抱开源
虽然 TiDB 本身的 Prometheus 也可进行数据的整合，但场景太过于单一，达不到预想效果。对于运维以及业务来说几十套集群上百个节点均需要做到告警消息及时告知、监控大盘、可在单一页面上便捷的查看所有Grafana信息、Dashboard监控可进行语句级别的查询。TiDB 是一款优秀的开源软件，本着拥抱开源的心态，经过大量的调研以及基于成本的考量，最终选择了在监控领域的开源产品夜莺。夜莺产品架构如下：
选择夜莺监控主要有两点：
1、兼容多个数据源接口，Prometheus、Zabbix、ES 等。这使得对于多套集群的 TiDB 无需做额外改动，只需要将 Prometheus 数据源接入即可获得所有采集数据。从而进行后续告警数据加工，且 ES 等数据源的支持也可为后续多集群日志整合提供可能性。
2、完全开源，成本低。无论是适配成本以及资源成本在同类产品中都占据优势。
工具安装与适配
详细的安装步骤请参考官网 安装部署详解 这里不在赘述。
由于整体项目为XC，监控也需要进行XC考量，所以将监控底层存储 MYSQL 替换为TiDB。Redis替换为某国产中间价。实际测试可百分百兼容。
业务组设计
整个监控的告警、监控不仅仅是面向 DBA，对应业务组的重要应用人员也有权知道后端数据库资源使用情况。业务组之间耦合性较低，每个业务仅关心自己的业务，DBA 则需要管控所有集群。针对此种场景在进行监控具体指标设计之前，需要按照不同需求进行业务组、角色、团队设计。
设计规则
用户管理：1、LDAP用户登录帐号，2、虚拟机器人+token地址（内部飞书告警）
团队管理：以一级部门名称+产品名称+业务系统命名（对应飞书接收群组名称），对应告警接收组 eg ：ITXX部门- TiDB-XXX业务系统
业务组管理：以产品名称+一级部门+产品名称+系统名称命名（对应告警规则组），此处第一个产品名称为自动折叠设置。
角色管理：告警机器人账户、业务组人员账户、监控管理员账户，不同角色不同权限。
告警规则制定
制定完成业务组后，第一步实现飞书自动告警功能。
添加数据源
为方便管理数据源命名规范为：
部门_中间件名_业务系统_环境_IP(prometheus)
eg：XXIT_TiDB_ JAVA_PRO_127_0_0_1
添加告警规则
告警管理-告警规则-点击对于业务组-新增，同样为后续运维性考量，需严格设置规范命名规则。其中PromQL规则则按照自我需求编写即可，后续我司规则将会提交至开源社区，感兴趣可参考。
规则名称：业务系统描述+告警简介
备注：对应告警集群
数据源：只关联业务系统对应的数据源
告警接收组：对应业务组
告警模板制定（此处可根据需求自行编写通知模板）
系统配置-通知模板-飞书
告警环境: 测试环境
服务名称: {{index .TagsMap "paasName"}}{{index .TagsMap "serviceName"}}
级别状态: S{{.Severity}} {{if .IsRecovered}}Recovered {{else}}Triggered{{end}}
告警对象: {{if.TargetIdent}}{{.TargetIdent}} {{else}}{{index .TagsMap "instance"}}{{end}}
规则名称: {{.RuleName}}{{if .RuleNote}}
规则备注: {{.RuleNote}}{{end}}
监控指标: {{.TagsJSON}}
{{if .IsRecovered}}
恢复时间: {{timeformat .LastEvalTime}}
{{else}}
触发时间: {{timeformat .TriggerTime}}
触发时值: {{.TriggerValue}}
{{end}}
发送时间: {{timestamp}}
成果展示
告警管理-业务组告警规则-不同业务组不同集群全部整合
飞书告警效果
FAQ
Q1：为什么 TiDB 多集群监控需要统一平台？
A：原文场景中，各业务需要物理隔离，导致 TiDB 集群数量越来越多。每套集群都有自己的 Dashboard 和 Grafana，DBA 要在多处巡检和配置告警，管理成本会快速上升。
Q2：夜莺在该方案中接入的是 TiDB 的什么数据？
A：原文方案主要是将每套 TiDB 集群的 Prometheus 数据源接入夜莺。夜莺兼容 Prometheus、Zabbix、ES 等数据源接口，为后续告警数据加工和日志整合留下空间。
Q3：业务组命名为什么要规范？
A：业务组对应告警规则组，团队对应告警接收组。命名规范可以让 DBA 管控所有集群，同时让业务人员只关注自己的业务集群，降低跨业务组维护成本。
Q4：本篇完成后还缺什么？
A：本篇主要解决告警融合和自动告警处理。原文结尾说明，下一章会继续介绍如何融合多集群 Grafana 和 Dashboard。
结语
本篇文章粗浅的介绍了如何通过夜莺补齐 TiDB 告警融合缺失的问题，当然文章篇幅有限，实际会有更多细节，如感兴趣欢迎垂询。
下一章将会介绍如何融合多集群 Grafana ，以及 Dashboard 部分功能实现，做到一个页面即可查看几十甚至上百节点集群的难题。
