先简单介绍一下MDC系统，MDC系统由京东自主研发，对下针对物理机、容器的基础资源使用情况，以及业务常用组件的性能实施监控；对上为用户提供高效的监控数据服务和告警服务。

系统的总体架构很简单，功能划分得也很清晰，将采集与任务管理解耦。任务可以无状态地在Agent间迁移，方便横向扩展。

主要分为三部分：

1. Dashboard，Web-UI。

2. Controller，控制器。对内负责采集资源的管理和采集任务的调度，对外提供丰富的数据获取，报表生成接口。

3. Agent，采集器。实际的数据采集，告警执行者。

    

另外，我们在Controller上挂了一层VIP，把Controller服务整体封装成统一入口，可以方便采集服务（Agent）发现的实现和对外接口调用。

这里的Agent是一个逻辑上的概念，实际包含采集、告警、数据处理等多个模块。

这是Agent内部的架构，这里列出了主要的四个部件，它们之间通过消息队列相互通信。

按消息流向来看，Central负责采集任务的处理，并把任务下发到Sniper。

Sniper功能划分得很简单，它只用来做数据采集，没有掺杂其他业务逻辑，这样能在一定程度上保证采集效率不受干扰。

Sniper在采集完成后，通过消息队列将采集到的数据返回到Central中，Central在对数据处理完成后，将其发送到Filter和Collector的队列中。

Filter负责过滤数据，进行告警。Collector进行数据处理聚合，然后将数据放入缓存，存储。
 

采集Sniper，用插件的方式实现不同采集类型的灵活加载。

目前通过SNMP+IPMI，采集物理机的资源使用情况和一些硬件信息。

容器采集的实现，是在宿主机上部署DockerPull采集代理，对外暴露RESTful Api，Sniper通过RESTful Api通用插件获取其数据。
 

告警设置包含三部分，用户组、告警组和资源组。支持多级别、多阈值、多间隔、多种通知途径的规则设置，最大程度的方便用户订制告警。

从前面的运营数据可以看出，MDC系统承载监控目标的量还是很大的，而且增速较快。所以在设计之初，我们就确定了几个设计目标：高性能、低开销、高扩展、高可用。接下来分享我们在这些方面的一些实践。

MDC的数据采集采用了“pull”的模式：通过SNMP和IPMI协议获取物理机的监控信息，通过在目标节点上部署Agent，获取容器的监控信息。

实践中遇到的性能问题，只要集中在物理机的数据采集上：

首先是SNMP采集的优化。由于我们开发用的Python语言，在做SNMP处理时，自然而然地找到了Pysnmp这个pure-Python的SNMP实现。但是在测试时发现，Pysnmp这个库可能是由于Python本身并发限制的问题，效率并不能满足我们的要求。解决思路就是底层采集使用C或者其他更高效的实现来做，我们对比选择了Netsnmp这个C的SNMP实现。通过测试，发现Netsnmp在并发处理时，效率远高于Pysnmp。

其次是IPMI采集的优化。IPMI可能是由于协议本身或者BMC芯片采集效率的问题（具体不明），导致数据返回缓慢（分钟级）。IPMI的采集效率问题无法从源头解决，所以我们在实现中做了一些实时性方面的妥协，解决思路就是在IPMI的采集模块中加入缓存，缓存会被定时刷新，同时接受到IPMI采集请求时，会立即返回缓存中的数据。

然后是慢采集的优化。由于网络，目标机性能等原因，会出现一些采集较慢的目标机。这些慢采集我们做了两层处理，首先是在采集任务内，将慢采集做自适应降级处理，这样既能保证慢采集目标的数据可用性，又不会影响采集任务内其他目标机的采集。其次在采集任务间，如果慢采集影响了任务的整体性能，会通过将任务做拆分，迁移处理来保证任务整体的采集效率。
 

低开销是我们监控系统设计的另外一个原则，就是尽量降低监控系统本身对生产环境资源的损耗。我们把各个组件（Central、Sniper、Filter、Collector）和它们之间交互所需要的消息中间件（RabbitMQ）打包成一个逻辑上的Agent部署在一台物理机或者容器上。

这样做有两个好处，一个是避免了大规模集群环境下，RabbitMQ的性能瓶颈问题。另外一个，除了采集和存储时产生的必要的网络流量，组件之间的数据交互都在机器内部进行，不会流向机器外部，对网络做成额外压力。
 

主要从三个层面做了高可用的处理：进程存活、服务存活、采集业务存活：

1. 进程存活，保证相关进程存活，进程挂掉时自动重启；

2. 服务存活，保证服务整体可用，部分服务挂掉不影响整体可用行；

3. 采集业务存活，保证采集任务不丢失。