背景

随着公司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}}

成果展示

告警管理-业务组告警规则-不同业务组不同集群全部整合

飞书告警效果

结语

本篇文章粗浅的介绍了如何通过夜莺补齐 TiDB 告警融合缺失的问题，当然文章篇幅有限，实际会有更多细节，如感兴趣欢迎垂询。

下一章将会介绍如何融合多集群 Grafana ，以及 Dashboard 部分功能实现，做到一个页面即可查看几十甚至上百节点集群的难题。