转载

新浪是如何设计监控10w服务器的？

1. 现状

如今，对于一个创业型的小公司而言，业务规模还比较小，选择一个开源的监控系统是一个非常高效的解决方案，但是，随着业务规模的快速增长，监控对象越来越多，也越来越复杂，以及为了实现公司的一些特殊需求，现有的开源的监控系统在性能、扩展性、和用户的使用效率方面已无法支撑。

而作为一家成熟型互联网公司，通过大家的努力，我们已经有了非常完善的框架体系，涵盖了分布式log、监控、实时报警、大数据存储等等方面，在整个运维至关重要要环节中，我们设计了一个可以支撑10万台服务器的监控系统，那么，我们是如何实现的呢？

目前，我们的服务几乎覆盖全公司所有部门，其中主要有微博、数据库平台、数据系统服务平台、新浪内容加速平台、网络核心、云计算应用平台、门户广告等，处理metric数据写入20万个/秒，habase请求数50万/秒，且每天发送报警总量多达15万条。

2. 软件架构

新浪是如何设计监控10w服务器的？

图1 展示了从服务器数据收集到异常报警的流程，接下来会对各个组件结合实际应用进行描述。

2.1 如何保证Agent数据发送Proxy?

“当数据量大了，P大点事都是大事”，新浪有数据以万计的服务器需要监控，而且这些服务器被放到了不同的机房甚至不同的城市。我们需要解决的几个主要问题，如下：

如何保证数据发送速度？
如何保证数据完整？
如何保证安全？
为了保证数据能快速发送到Proxy，我们在几乎每个机房都部署了Proxy。这样Agent的数据不跨机房发送速度是有保障的，但是问题又来了Agent怎么知道自己该选择哪个Proxy呢？是的，管理员知道。如果让管理员手工配置这些信息你觉得怎么样？他一定会骂人的。于是，为了不被骂我们把Agent搞的尽量智能一些，我们的原则就是不给别人添麻烦，一开始我们通过收集一些信息和公司强大的CMDB对比可以得知这些信息，因此Agent在启动的时候就可以确定自己该选择哪个Proxy，但是还是需要管理员进行选择，还是不够智能，怎么办？后来，我们又填加了统一域名调度服务功能，通过来源分析IP所在机房，我们就可以实现自动分配对应所在机房的proxy。
Agent可以顺利把数据发送给Proxy了，但是Proxy往Kafka写呢？还是会有跨机房、网络不稳定等各种意想不到的情况，数据如果不能快速送到Kafka，我们便增加了Proxy缓存功能，将不能及时发送的数据先保存下来，好在目前这个功能线上应用次数很少很少。
至于安全问题，其实主要考虑不能随便一台服务器或一个程序都可以调用Proxy的接口，最简单的方法是账号验证，除此之外Agent在启动的时候会将一些信息发送到验证中心，只有验证通过Agent才能正常启动，否则Agent是不能启动。
2.2 Proxy的重要性？
从图1上可以看出Proxy的主要任务是接收数据，可以说Proxy是一个功能单一，但是非常重要的角色，它是所有数据的入口。除了接收数据又增加了如下功能：
身份认证，为了防止恶意写入数据，增加身份验证；
统计写入量，统计用户或应用的数据写入量；
后来发现统计写入量这个功能对运维同学来说是非常有用的，当数据出了问题可以从写入量来排查问题。
2.3 Storm的监控
数据由Proxy写入kafka，之后由Storm来消费，在实际生产环境中遇到最多的问题是：
Supervisor负载不均衡；
读Kafka失败；
负载不均衡的情况通常是某台服务器负载太高，曾遇到问题是各supervisor的网络被占满（有新产品上线）导致Storm集群通信不畅，彼此不知对方是死是活；
至于读Kafka失败通常是网络问题引起。
这是我们在使用Storm时遇到的问题，为了保证为Storm正常运行。我们写了一个监控Storm运行状态的脚本，其实思路很简单就是定时抓取Storm UI，分析各状态值。
2.4 TSDB遇到的问题及踩过抗
最开始使用的OpenTSDB的版本是1.0还是0.X记不太清了，当时其提供的API性能不能满足需要，故将其源代码进行修改添加了Thrift接口；
Region Server重启的问题
OpenTSDB是基于Hbase存储数据的，发现OpenTSDB很大的一个坑是当Hbase集群中有任何一台Region Server重启之后OpentTSDB都有丢数据的情况，只有重启所有OpentSDB节点才能恢复这个问题。
OpentTSDB升级后时间戳长度变化
在1.x版本中其时间戳长度是10位精确到秒，升级到2.0后其时间戳长度为13，其实这个改变对我们自己的应用本身没有问题，但是从升级后一些使用我们服务的用户反应查不到数据，后来经过排查才知道原来是时间戳长度发生了变化。
2.5 报警平台
报警平台借鉴了Storm流式处理数据的思想，整个报警平台分为多个模块，每个模块的功能类型Storm中的bolt对数据只做一项处理，处理完成之后将数据转到下一个模块。
目前报警平台每天有上百万次的调用，其中大部分请求是需要发短信和邮件的，这样每天的短信费用也是相大的一笔开销，而且经过我们长时间的观察及优化报警平台的算法，在不影响正常报警的同时，将每天的报警请求数量与实际的报警数量比率降低到了10：1。主要的方法，如下：
校验联系人，由于使用报警平台的用户很多而且各部门人员变动也很频繁经常出现报警联系人已离职但是报警还在发，为了避免这样情况的发生报警平台会对联系人与ERP系统对比；
报警合并，对于同一个问题的报警，根据关键字提取方法首先确定报警针对的问题是同一问题后，将多条报警合并为一条，这样避免了发送多条消息浪费资源，同时也不影响管理员解决问题；
## 3. 小结 ##
在过去的一年多的时间里，本文算是在监控报警上做的一些工作的总结，事实上，在后面的日子里，我们还有很多功能需要优化：