拉卡拉开放平台

很多系统的监控面板堆满了图表，真出问题时却不知道该看哪个。问题不在于指标太少，而在于没有想清楚每个指标回答什么问题。

四类基础指标

为什么只看平均值会漏问题

平均耗时正常，可能是一半请求极快、另一半极慢相互抵消的结果。而用户感受到的，是那慢的一半。

因此除了平均值，还应关注分位值——例如绝大多数请求落在什么范围内，以及最慢的那一小批有多慢。

告警阈值怎么定

• 不要用固定值，应参考历史波动范围；
• 持续时间比瞬时值更重要，短暂抖动不必告警；
• 分级告警：轻微异常记录，严重异常立即通知。

阈值定得太敏感，告警会多到没人看；定得太迟钝，等告警时问题已经扩大。

指标与日志如何配合

指标负责发现问题，日志负责定位原因。两者要有共同的标识可以直接关联：

1. 指标异常时，确定异常发生的时间段；
2. 用时间段去日志里筛选对应记录；
3. 从记录里找到具体请求与失败原因。

如果指标和日志各说各话，这个链条就会断在第二到第三步之间，排查会非常痛苦。

一个实用建议

先只做四类基础指标，把它们做扎实，再根据需要逐步扩展。十个没人看的指标，不如四个真正被用起来的指标。

指标的时间粒度

同一个指标在不同时间粒度下，呈现的信息完全不同。

实践中通常同时保留多种粒度：分钟级用于告警，小时与日级用于分析。

面板的组织方式

• 按发现问题的顺序排列，而不是按数据来源排列；
• 最常用的指标放在最显眼的位置；
• 每张图都要能回答一个明确问题。

第三条是检验标准：如果一张图说不清回答什么问题，它多半是可有可无的。

告警之后的动作

告警只是起点，更重要的是收到告警后该做什么。

1. 确认影响范围：是个别现象还是整体故障；
2. 判断紧急程度：是否需要立即回滚或切换；
3. 记录处理过程：便于事后复盘。

没有配套动作的告警，只会让人逐渐麻木，最终在真正重要的一次被忽略。

不要忽视对账类指标

技术指标之外，还有一类指标直接关系到资金正确性：对账差异数量与差异类型分布。

• 差异数量突增：通常意味着某处逻辑发生变化；
• 新增差异类型：说明出现了以前没有的情形；
• 差异长期不降：说明处理流程存在堵点。

这类指标的变化往往比技术指标更值得警惕，因为它们直接影响账目是否正确。

监控的终点不是图表，而是行动。每一个指标都应该对应一个明确的问题和一个明确的处理动作，否则它只是屏幕上的装饰。

指标体系的成熟度，往往与团队对系统的理解深度同步。想清楚要看什么，本身就是在想清楚系统是怎么运转的。

指标不在多，在于每一条都能在出问题时给出明确指向。能做到这一点的监控系统，才是真正被依赖的那一个。