这既是广告，又不是广告，关键在你怎么看。

之前有同行Randy素年锦时谈到在运维过程中监控报警的设计和优化，很有感触。我顺势简单说说阿里巴巴数据交换平台(DXP)在复杂分布式平台上的一些稳定性实践。

从技术上来讲，DXP大概囊括了有那么几个分布式计算集群，有基于Hadoop的，也有基于ODPS的，也有其他一些长在离线计算平台之上的在线系统和流处理系统。每个集群大概有数千台机器，部署着上百个异构的组件（模块）。要命的是，这些组件之间一定是有复杂的依赖关系的，一个组件的异常可能导致一系列连锁反应。

另一方面，长在技术平台上的数据业务，本身更加复杂，并且在不断变化。终端数据的产出链条非常长，依赖的上下游错综复杂。一份数据的产出延迟、出错或者质量不达标，造成的影响有着千差万别。

我们为这个平台的监控体系取了个很理想主义的名字——摩萨德。一些基本的思路如下：

• 平台和业务在快速地变化，一定要减少人在监控规则、阈值管理上的投入；
• 对技术和业务的有向无环图（DAG）做全局监控，各个点采集到的信息要整合、共享起来；
• 做根本原因的分析，把报警发给能直接影响结果的人；而不是让人找人；
• 做影响面和紧急程度的预测和分析，在恰当的时机发送报警，尽量避免对工程师业余时间的干扰，尤其是起夜；
• 建立平台稳定性指标，推进整体稳定性的长期改进。

举例来说：

凌晨2:00一个离线任务A出错了，摩萨德是这么工作的：

• 拿到A执行过程的详细日志，对其做文本分析，抓取特征；
• 结合实时抓取到的各个组件的状态数据、BUG信息等计算出A的出错是由组件x(值班人X)导致的；
• 从调度依赖关系中判断，A在B(15:00)和C(12:00)两个终端数据的产出路径上，这是影响面；
• 根据以往的运行情况，结合整个集群、上下游的运行数据，预测A->B，A->C的后续路径余量；
• 我判断到A的出错最晚可以容忍到10:00处理，那么在凌晨2:00不会发报警；
• 如果在10:00之前有其他必须马上处理的告警发送给用户X，那么A的出错会一并推送给X；
• 否则，到9:00开始向X推送A的出错信息，同时CC给A的owner。

在这个过程中，准确地根源分析和对后续执行情况的预测都是很大的技术难点，涉及多方面的算法和数据处理技术，很有挑战。

从根本上来讲，平台监控能做到什么程度，取决于我们对整个平台的技术架构和业务模型的掌握和理解程度。我们正在寻找这样的人。

[pengchun@alibaba-inc.com](mailto:pengchun@alibaba-inc.com)