Uber有成千的微服务支撑着各种各样的Uber的业务。Uber的运维团队为了保证及时发现这些微服务及其运行的环境的问题，设计了一套功能强大的、易扩展的监控系统。
整体架构
监控组件uMonitor和Neris。
uMonitor完成基于metrics的监控，它从存储Metrics的数据库Cassandra M3中读取Metrics
并根据告警规则来判断是否要发送告警。
Neris主要是对于微服务所运行的环境例如主机的CPU、内存以及磁盘进行监控，并判断是否要发送告警。
uMonitor和Neris的告警都统一发送到告警组件Origami，Origami接收告警请求并将告警归并后发送到与之对接的响应系统中，对微服务中的错误做出快速响应。Origami的巨大挑战来自于如何在大量的告警噪声中提取出有价值的告警信息。
另外，Uber在全球有多个DC部署微服务来支撑全球的业务，所以需要考虑DC之间的相互监控，防止某个DC的监控系统出问题不能正常工作时候的极端case，这里Uber监控框架中的Blackbox就是完成这种DC级别的监控。
uMonitor架构
uMonitor是基于业务Metrics的监控组件，它的结构如下：
Uber的监控系统中的Metrics搜集API负责收集微服务发过来的Metrics，并将它写入到存储Metrics的数据库M3中。
uMonitor的Scheduler会一分钟驱动所有运行监控规则的Workers执行监控任务，worker从M3中读取Metrics和监控Rule进行监控判断。
将状态结果存入监控状态存储数据库Cassandra中国。同时将需要发送告警的信息发到告警统一处理网关中。
Neris架构
Neris主要是对于微服务所运行的环境的监控组件，它的结构如下：
在每台server中安装的Host Agent搜集上来的数据，发送到Neris中进行聚合运算，然后将告警信息发送到告警系统Origami中。
本文来自投稿，不代表本人立场，如若转载，请注明出处：http://www.sosokankan.com/article/2004000.html