Node.js在分布式平台监控中的应用
发布于 10 年前 作者 pengchun 7497 次浏览 最后一次编辑是 6 年前

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

之前有同行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)

5 回复

平台监控 - 用到 SNMP 和软硬件打交道吗?

没有。我们做的是应用层面的监控。基础通用监控公司有成熟的产品的

CA 好像有类似的产品,带三维显示的。

DAG 要存在 Graph 数据库里吗?nodejs 有 DAG 的库用来构建和查询?

10w规模的节点我们都是在内存里计算的。

@pengchun 学习了,在理。

回到顶部