实时通讯系统的数据库性能监控指标设置
做实时通讯系统这么些年，我越来越觉得数据库这块的监控就像人体的神经系统看着不起眼，但关键时刻出问题那是真要命。去年有个项目，用户量上来之后数据库响应突然变慢，排查了半天才发现是某个关联查询没建索引导致的。那次经历让我深刻意识到，数据库性能监控这件事，前期偷的懒后期迟早要还。
作为一个在音视频云服务领域深耕多年的团队，我们服务过全球超过60%的泛娱乐APP，每天处理的实时消息量级说出来可能很多人不信。但数字背后是什么？是无数个需要我们精心守护的数据库实例。今天想从头捋一捋，实时通讯系统里数据库性能监控的指标到底该怎么设置，希望能给正在做这件事的朋友一些参考。
为什么实时通讯系统对数据库监控要求更高
很多人可能会问，数据库监控不就是那些老一套的指标吗？QPS、连接数、慢查询、CPU使用率这些，难道还有区别？
说实话，区别大了。实时通讯系统的特点是什么？是低延迟、高并发、实时性强。用户发一条消息，对方恨不得马上收到；一个群里有几千人同时说话，数据库要在毫秒级完成读写。更别说我们这类做音视频云服务的，还会涉及到用户状态管理、房间信息维护、消息历史存储这些高频操作。
举个简单的例子，普通的电商系统可能每秒几千次数据库请求已经算多的了，但在我们这种1v1视频社交场景下，高峰期每秒几万次的用户状态更新都是常规操作。这时候如果数据库响应慢上几百毫秒，用户可能就直接挂断找别家了。所以实时通讯系统的数据库监控，不仅仅要发现问题，还要能在问题影响用户之前预警。
核心监控指标体系
根据我们的实践经验，实时通讯系统的数据库监控指标可以分为几大维度。每个维度都有其独特的意义，设置的时候也需要不同的策略。
连接与会话类指标
数据库连接是所有操作的起点，这块的监控一定要盯紧。我们主要关注这么几个指标：
| 指标名称 | 说明 | 预警建议 |
| 当前活跃连接数 | 正在执行操作的数据库连接数量 | 达到最大连接数的80%时预警 |
| 连接等待队列长度 | 等待获取连接的请求数量 | 持续超过10就需关注 |
| 连接建立成功率 | 新建连接的成功比例 | 低于99.9%需要告警 |
| 平均连接持有时间 | 一个连接从建立到释放的时长 | 过长可能存在连接泄漏 |
这里有个坑我们踩过很多次。早期为了追求性能，把数据库连接数设得很大，结果遇到业务高峰期连接数直接打满。后来学乖了，连接数的设置要根据业务特点来，不能盲目调大。实时通讯系统的特点是请求频繁但单次处理时间短，所以连接周转率很高，这时候与其堆连接数，不如优化查询效率。
查询性能类指标
查询性能是数据库监控的重中之重，直接影响用户体验。我们内部把这块分为几个层面来看：
响应时间类：平均响应时间、P95响应时间、P99响应时间、最慢响应时间。这几个指标一定要配合起来看，只看平均值容易被误导。比如平均响应时间可能是50毫秒，但P99可能是500毫秒，这时候大部分用户感觉没问题，但有1%的用户已经骂娘了。实时通讯场景下，我们对P99的要求是不能超过200毫秒，超过这个数用户就能明显感觉到卡顿。
慢查询类：慢查询数量、慢查询分布、重复慢查询占比。慢查询的定义我们设置的是执行时间超过100毫秒的查询。但光看数量不够，一定要分析这些慢查询都是什么类型的。在我们的场景里，最常见的慢查询包括：未正确使用索引的全表扫描、JOIN操作涉及的表过多、没有分页的大量数据查询。建议每周至少review一次慢查询日志，把重复出现的慢查询优化掉，这比临时抱佛脚有效得多。
查询类型分布：SELECT、INSERT、UPDATE、DELETE的比例变化。这个指标很有意思，正常情况下比例应该是稳定的。如果突然INSERT的比例上升，可能是某个功能被批量调用了；如果UPDATE激增，可能是有业务逻辑在频繁更新状态。掌握这个比例，能帮你提前发现业务层面的异常。
吞吐量与并发类指标
吞吐量反映的是数据库的处理能力上限，并发则反映的是当前的压力状态。这两个指标结合起来看，才能判断系统是否健康。
- QPS/TPS：每秒查询数/每秒事务数。这是最基础的吞吐量指标，但不能孤立看待。比如QPS从1万升到2万不一定是坏事，如果响应时间没变化说明系统还能扛；如果QPS没变但响应时间涨了一倍，那就说明压力已经接近瓶颈了。
- 并发请求数：同时在处理的请求数量。这个指标在实时通讯系统中波动很大，业务高峰期可能瞬间冲很高。我们做过压测，单数据库实例在并发请求超过2000时，性能下降会比较明显，所以会把告警阈值设在1500左右。
- 读写分离状态：如果用了读写分离，需要监控主从同步延迟、读写请求分配比例。实时通讯系统对数据一致性要求高，主从延迟超过1秒就可能出问题了。
资源利用类指标
资源是性能的基础，资源不够再好的优化也白搭。
CPU使用率：这个要分核心来看，多核CPU的平均使用率可能只有60%，但如果某个核心长期90%以上，说明存在不均匀的情况，可能是某个查询把单核吃满了。实时通讯系统的数据库操作通常比较轻量，CPU不应该成为瓶颈，如果CPU持续过高，先检查是不是有慢查询在占用资源。
内存使用：包括物理内存和Swap使用。数据库的内存缓存很重要，缓存命中率直接影响查询速度。我们会重点关注InnoDB Buffer Pool的命中率，低于99%就需要排查原因了。另外Swap如果频繁使用，说明物理内存已经不够用了，这时候加内存比什么都管用。
磁盘I/O：包括读写吞吐量、I/O等待时间、磁盘队列深度。实时通讯系统的数据库读写很频繁，尤其是消息历史这种存储，磁盘I/O往往是第一个出现瓶颈的地方。我们建议用SSD，而且要把日志盘和数据盘分开，避免互相影响。
稳定性与错误类指标
这类指标平时可能看着都是0，但一旦出现异常就是大问题。
| 指标名称 | 监控意义 | 处理建议 |
| 连接失败次数 | 反映网络或配置问题 | 立即告警并检查网络和配置 |
| 死锁发生次数 | 反映事务逻辑问题 | 分析死锁日志优化事务顺序 |
| 反映查询性能严重恶化 | 紧急排查慢查询和资源瓶颈 | |
| 主从同步中断 | 反映复制链路问题 | 立即介入处理数据一致性风险 |
这里我想说，错误指标比性能指标更重要。性能指标是慢慢恶化的，有预警时间；错误指标往往是突然出现的，一出现就可能影响业务。我们内部的策略是错误指标设为最高优先级告警，哪怕半夜也得爬起来处理。
阈值设置的艺术
指标监控最难的不是采集数据，而是设置合理的阈值。阈值设得太松，出了事才报警；设得太严，动不动就告警，运维人员很快就疲劳了，反而容易忽略真正的异常。
我们的做法是分级告警。每个指标设置三个级别：关注、预警、严重。关注级别用于日常观察，可以在看板上展示但不需要立即处理；预警级别需要安排人员排查；严重级别必须立即响应。
举个例子，CPU使用率我们是这样设置的：
- 关注：60%以下——正常运行区间
- 预警：60%-80%——开始排查原因，准备扩容或优化方案
- 严重：80%以上——立即处理，可能需要限流或扩容
但这只适用于普通情况。如果是凌晨2点业务低峰期，CPU到了70%可能只是正常的后台任务在跑；如果是业务高峰期，70%可能已经在悬崖边上了。所以有些指标需要结合时间维度来判断，设置不同时段的差异化阈值。
还有一个原则：阈值要随业务增长动态调整。系统用户量从10万涨到100万，原来合理的阈值可能就不再适用了。建议每季度review一次阈值设置，根据实际运营数据做调整。
实践中的几点心得
说了这么多，最后分享几点实操中的心得吧。
第一，监控数据要保存历史记录。很多问题需要对比历史才能发现，比如某个指标最近一周都在缓慢上升，虽然还没触发告警，但趋势不对就需要提前干预。我们一般保留至少90天的监控数据，关键指标保留一年。
第二，告警要聚合不要轰炸。同一个原因导致的告警要聚合起来，否则一秒钟弹出几十条告警，运维人员根本来不及看。我们会用告警收敛策略，把同一类告警合并成一条通知。
第三，监控要为业务服务。不是为了监控而监控，每个指标都要能对应到业务影响。比如慢查询数量这个指标本身没意义，要转换成"预计影响用户数"才有价值。我们会在告警信息里加上业务影响的预估，帮助团队判断优先级。
第四，定期做故障演练。不清楚监控体系好不好用，模拟一次故障就知道了。我们每季度会做一次演练，人为制造问题看监控体系能不能及时发现、告警能不能送达、处理流程顺不顺畅。这个过程能暴露很多平时看不到的问题。
做实时通讯系统这些年，我越来越觉得数据库监控是个需要持续投入的事情。业务在发展，用户量在增长，监控体系也要跟着进化。那些在监控上偷懒的时刻，最后都会变成深夜加班排查问题的夜晚。
不过话说回来，看到自己监控的系统稳定运行，用户体验流畅，这种成就感也是做技术为数不多的高光时刻了。与各位共勉吧。
