监控的分层视角：概览、集群、节点、主机

TeleDB 的监控不是单张大盘，而是按层级拆开的。最上层是监控概览，展示整个集群的全局信息，包括全局事务管理器、协调节点和数据节点的运行状态、主机地址、主备角色、CPU 与内存占用。概览的价值是“一眼知道集群还活不活”，节点异常会直接标红。

往下是集群监控，把各数据节点汇总成集群级曲线：容量占用率、总请求数、读写请求拆分、总连接数。集群级指标抹平了单节点波动，适合看业务侧吞吐趋势——比如发现写请求数陡降而读请求数平稳，大概率是写入链路或业务批处理挂了，而不是数据库崩了。

再往下是节点监控，按协调节点、数据主节点、数据备节点、全局事务管理器分别展开。协调节点看 SQL 执行耗时、连接数、QPS、TPS、表扫描次数；数据节点额外看缓存命中率、主备日志同步差异、剩余事务号数量；全局事务管理器特殊，只监控主节点，看获取时间戳次数与平均耗时、序列获取耗时。节点级监控是定位“到底哪个角色出问题”的显微镜。

最底层是服务器指标，脱离数据库角色看宿主机：CPU 负载、内存占用率、磁盘占用率、网络出入流量、TCP 连接数、IO 队列长度、文件句柄数、进程数。这一层常被人忽略，但很多“数据库变慢”其实是宿主机磁盘 IO 饱和或 TCP 连接数打满的锅。

核心指标语义：哪些曲线先动

TeleDB 节点监控里几个指标最该被钉在首页。

SQL 执行耗时分平均、最大 Top10、最小 Top10 三组。平均耗时反映整体健康，最大 Top10 暴露慢查询尾巴——平均没变但最大耗时翻倍，说明有个别查询在拖后腿。缓存命中率掉下来，意味着缓冲池不够或热数据被挤走，读请求会往磁盘跑，耗时连锁上升。主备日志同步差异持续增大，是备节点追不上主节点的信号，可能网络抖、可能备机 IO 慢、也可能主节点写峰太高。剩余事务号数量逼近阈值会触发告警，不处理会导致事务号回卷，是分布式库里少有的硬故障前兆。

集群监控里的容量占用率要和历史曲线一起看。只盯当前值容易误判——容量从三成涨到五成如果是一夜间发生的，比缓慢涨到七成更危险，因为前者可能是日志或临时表爆增。读写请求数的比例也能讲业务故事：读多写少是典型分析混合负载，写多读少是交易高峰，比例突变往往对应上线或跑批。

告警规则：把阈值变成可执行的动作

TeleDB 的告警分指标告警和事件告警两类。指标告警挂在具体曲线上，比如节点 CPU 使用率、内存使用大小、磁盘占用量、Xlog 文件数量、SQL 平均执行时间、每分钟各类请求数、缓存命中率、当前连接数、剩余事务号。事件告警挂在状态变更上，比如实例状态、全局事务管理器状态、协调节点状态、数据节点状态切换。

配置告警时容易犯两个错。其一，阈值抄默认值不结合业务。交易系统白天写请求高是常态，若按文档示例给写请求数设绝对阈值，白天会天天误报；正确做法是按同比环比浮动，或分时段套用不同阈值。其二，只配节点告警忘了机器告警。数据库进程没死但宿主机磁盘满了，节点指标可能还正常，机器级磁盘使用率告警才是第一道防线。

告警的检测频率有不同档位可选，指标类通常按分钟级检测。生产环境建议把“剩余事务号”“主备日志同步差异”“磁盘占用量”设成高频检测，把“QPS 波动”设成低频，避免噪声疲劳。告警出来不是给人看的短信，而是该直接关联预案：磁盘快满触发清理归档日志脚本，主备差异大触发手动切备，事务号紧张触发安排维护窗口。

日志与慢查询：文本层的补充证据

监控曲线告诉你在哪段时间异常，日志告诉你是哪条 SQL、哪个会话、哪次锁等待。TeleDB 控制台支持日志管理，可将实例日志归集到对象存储桶，便于长期留存和全文检索。

慢查询是日志里最该被定期捞出来复盘的一类。平均 SQL 执行耗时上涨时，去慢查询日志里按耗时排序，常能直接看到一张大表全扫、一个没命中索引的 LIKE 查询、一个跨分片广播的聚合。分布式场景里还有一种典型慢查询：单分片数据倾斜导致某数据节点 Execute 阶段特别长，其他节点早早返回，合并阶段被拖住——这种在集群总耗时里不明显，必须下钻到节点监控和 Query Profiling 类工具才能看见。

日志运维的纪律是：别等出事才开全量日志，平时开慢查询日志和连接异常日志即可；日志保留周期和监控数据保留周期（默认一个月）对齐，避免曲线能看一个月前、日志却只剩三天。

主备切换与高可用运维

TeleDB 每个角色都有主备：全局事务管理器主备、协调节点主备、数据节点主备。控制台提供主从切换操作，可选指定备节点切上。日常运维里主备切换分两类：计划内（升级、规格变更、宿主机维护）和计划外（主节点宕机、网络隔离）。

计划内切换要在低峰期做，切之前确认备节点日志差异已追平、备机资源够吃主节点负载。切完不是结束，要观察原主降备后是否能稳定作为备节点重连，避免脑裂残留。计划外切换由高可用机制自动触发时，运维要做的是事后复盘：为什么主节点掉线、切换耗时多少、切换期间事务有没有丢、应用连接池有没有雪崩。

一个常被忽略的点：应用侧连接串如果只写死主节点地址，主备切换后连接会断。正确做法是走协调节点负载地址或 SDK 支持自动感知拓扑，让切换对应用透明。这也是为什么实例监控里“节点状态”事件告警必须接应用侧告警群——数据库切了，应用不知道就等于故障没恢复。

容量、规格变更与在线升级

容量运维不是等磁盘满了再扩。TeleDB 控制台支持节点规格变更，但变规格要重启或迁移对应节点，计划性很强。正确节奏是容量占用率摸到七成就开始评估扩容，同时查数据目录里是不是 Xlog 或归档挤占——前者调检查点频率，后者调归档清理策略，不一定非得扩盘。

在线升级是另一项计划运维。控制台支持选择升级版本与目标节点逐步升级，任务进任务管理页跟踪。升级前必须确认：业务是否依赖某版本特有语法、升级窗口是否避开跑批、备节点先升主节点后升的顺序有没有遵守、回滚预案有没有备好。分布式库升级最怕“协调节点升了、数据节点没升”导致协议不匹配，因此升级任务要按控制台指引整实例推进，不要手痒只升单个节点。

排障闭环：从曲线到根因的路径

一个典型排障例子：业务报“下午三点后订单写入变慢”。进监控概览看节点状态都绿；进集群监控看写请求数没降，但总耗时涨了；下钻节点监控发现其中一个数据主节点 SQL 最大 Top10 耗时翻倍、缓存命中率掉十个百分点、主备日志差异在涨；再看同主机服务器指标，发现该宿主机磁盘 IO 等待时间陡增；最后翻日志看到大量检查点刷盘。根因是宿主机 IO 饱和导致主节点写吞吐下降，备节点追日志变慢是次生现象。处理动作是临时把该节点部分分片切到同机柜其他节点、联系平台调宿主机 IO 配额、后续把该节点迁移到独立盘。

这条路径的通用性是：概览定生死、集群定方向、节点定角色、主机定资源、日志定语句。五层顺着走，很少查错地方。

结语

TeleDB 实例监控运维不是把控制台每个按钮点一遍，而是建立一套“分层看数、阈值即动作、日志补证据、切换有预案、容量提前半步”的纪律。开发工程师在对接 TeleDB 时，最该摆脱的习惯是“数据库有问题时才登控制台”——日常把监控概览当状态栏、把节点监控里 SQL 耗时和主备差异当血压计、把告警规则当成自动值班的同事，实例才不会在半夜把你叫醒。分布式数据库的稳定，七分靠架构、三分靠运维眼睛够不够早。把控制台提供的这几层视野用熟，TeleDB 在官网宣传里那些“实时、融合、高稳”的形容词，才会落进你自己的巡检表里。