作者介绍

本文作者是吴城 联系方式：[email protected]，主要负责汽车之家云平台的开发和管理工作。 个人Blog http://jackywu.github.io/

团队介绍

我们是汽车之家运维团队，是汽车之家技术部里最为核心的团队，由op和dev共同组成。我们的目标是为汽车之家集团打造一个高性能，高可扩展，低成本，并且稳定可靠的网站基础设施平台。 团队技术博客地址为 http://autohomeops.corpautohome.com

前言

每个公司都有一套监控系统，或大或小，或简单或复杂。 汽车之家的监控系统最初使用的是Zabbix，从双机冷热备，到用Proxy构建分布式模式，到实现跨机房的灾备，这一路走的跟大家想象中的差不多。

一、历程

那为什么后来要新做监控系统呢？

Zabbix有几个短板

• 重度依赖数据库，无法支持超大规模集群的监控

• Zabbix Server端模块化程度低，二次开发不灵活

我们希望能够有一个分布式的，更加具有扩展性的系统架构。

二、我们的设计思路

我们对系统的设计目标是

• 精准告警

• 自动定位

• 故障自愈

该系统的产品定位

• 运维提供监控系统，负责系统的稳定性

• 业务运维能够自助使用该系统，关注基础监控的配置和告警接收

• 业务部门能够自助使用该系统，关注业务监控的配置和告警接收

根据我们对监控系统的研究，我们认为我们需要这样的架构

概念解释

• Agent：负责采集数据。

• Transfer：负责将采集到的数据转发到不同的后端。后端包括：分析器，存储，等等组件。

• Storage：历史数据存储。

• Dashboard：负责监控策略的配置和监控数据的查看。

• Detector：负责检测Agent上报的数据是否代表异常发生。

• Analyzer：负责分析Detector产生的异常事件行为，做一些逻辑后再发送告警。

• Sender：从Analyzer接收消息，发送告警通知。

• Processor：负责对异常事件进行自动化处理，即“自愈”。

三、我们的实现策略

根据这个架构我们去调研。 我们可以用非常基础的积木去搭建我们自己的系统，例如collectd，statsd，MySQL和HBase，或者类似的其他开源组件。 后来我们发现差不多相同时期小米开源了自己的监控系统Open-Falcon，我们的设计思路非常接近，所以我们就选择了在其基础之上进行二次开发。

四、产品设计

这里描述一下跟Open-Falcon在产品方面不同之处。

A. 服务树

我们根据公司的组织架构，加上业务系统的组织关系，构建了自己的服务树。 组织架构和服务器自动跟CMDB同步。

B. Dashboard

根据我们自己公司的业务组织形式，和以往的使用习惯，我们新建了自己的Dashboard。

1. 我们抽象出了“业务”和“功能模块”的概念，用来代表“系统”和“子系统”，或者“大分组”和”二级分组“的含义。Open-Falcon只支持一级分组。

2. ”功能模块“关联了”主机组“，”告警策略“，”告警模板“。

3. ”告警策略“里，我们实现了”告警升级“，”延迟告警“，按“功能模块”合并主机的告警。

4. 我们在页面上提供了对“功能模块”里主机告警的自助“订阅”功能。

这块内容我们后续会单独发文来分享。

C. 告警判断表达式

我们对Judge修改，新增了昨日对比函数

• daydiff（#3）>1：昨天和今天同时间对比，数据差值大于1

• daypdiff（#3）>1：昨天和今天同时间对比，数据差值大于1%

D. 告警通知策略

• 为了解决告警轰炸问题，我们增加了“告警升级机制”：告警发生后立刻发送给”组1”的人，X分钟故障还在持续则发送通知给“组2”的人，如此类推。组员和间隔可以定制。

• 为了进一步优化一个时间段内告警发生和恢复往复跳动导致告警泛滥的问题，我们增加了这样的机制： 在一个时间段内，告警首次发生，则立刻发送通知，然后利用拉长时间段的原理，抑制掉期间抖动的告警，时间段末尾处再发送故障或者恢复状态。时间段可以定制。

• 为了进一步优化一组功能相同(或者有其他角度共性)的机器同时发生同类异常导致告警泛滥的问题，我们增加了这样的机制：也是利用拉长时间段的原理，在时间段末尾，将属于同一个功能模块下的机器，按照相同监控项合并。时间段可以定制。

这块内容我们后续也会考虑开源。

E. Agent

汽车之家有大量的Windows服务器，为了实现系统逻辑架构的统一，我们基于Windows Service服务用Python开发了自己的Agent (author：ninjadq )。

该Agent跟freedomkk-qfeng/falcon-scripts的区别是：

1. 支持IIS和SQLServer的监控项采集。

2. 运行为Windows的Service，不用配置定时任务。Agent的运行模式跟Linux下的Go-Agent一致。

3. 每个应用软件一个线程，在应用采集不多，且是定期采集的情况下，线程切换的开销可以忽略不计。

4. 实现了本地的http代理接口。

跟LeonZYang/agent的区别是

• 不用给golang打patch。

在公司的支持下，我们将代码以Apache许可证开源。 参见”Windows Agent”https://github.com/AutohomeRadar/Windows-Agent/。 其中我们借用了”freedomkk-qfeng/falcon-scripts”部分采集代码，感谢作者的代码。

欢迎提交PR和Issue，欢迎用QQ或者邮件跟我们联系。

五、未来的Roadmap

1. 故障定位

1. 基于时间维度和语义的事件关联性分析

2. 网络和业务的可视化跟异常可能性分析

2. 动态阈值分析

3. 监控项行为分析 + 动态监控策略匹配

4. Judge/Graph/等等组件的多机房数据同步和冷备方案

六、小结

监控系统建设是一个任重而道远的漫长过程，只要需求不断，可能永远不会有停止的一天。 我们会和社区保持紧密沟通，吸取一些经验，同时贡献一份力量。欢迎大家通过上述方式跟我们交流。

商务合作联系微信yunweibang555