本文内容整理自去哪儿运维开发工程师张悦在第四期沙龙活动中的分享：《去哪儿网监控系统实践》。如需转载，请与工作人员联系获取授权。去哪儿网的运维团队基于开源项目Graphite+Grafana+Nagios二次开发了监控系统Watcher，用来支撑去哪儿百万级别的基础/业务监控指标。想不想知道去哪儿网监控系统Watcher的秘密？让我们跟随美女老师张悦的脚步，探索Watcher的设计、选型和架构，一窥去哪儿网监控系统的奥妙。美女介绍张悦去哪儿运维开发工程师于年加入去哪儿。一直从事运维开发，参与开发Watcher监控系统，现负责监控相关的开发和运维工作。我们为什么需要监控监控的重要性众所周知，但监控的目的归纳起来主要就是四点。第一点是实时报警，比如服务器、交换机挂了，服务访问不了了，或流量骤增被攻击了等等，我们通过报警第一时间发现问题，并通知相关的人员去处理。第二点是提前预警，比如通过看一个服务的qps、响应时间等监控指标，如果访问量大增、响应时间变长，提前预警出来，就可以考虑加大并发或用其他方式进行优化。第三点是追查问题，用监控快速的定位追查问题是很重要的部分，并且在去哪儿网有很多应用场景。例如当收到一个报警发现酒店的有效报价量突然间暴跌时，这里假如有个逻辑是有效报价等于总报价减去空报价，那么就需要去看一下总报价量是否下跌或空报价量是否上升了，然后具体情况具体处理。因为有很多监控指标之间是具备包含关系的，一个总指标可能是许多子指标通过计算得出来的，所以出现问题我们就需要详实的数据来定位问题、追查问题。第四点是容量规划，比如MFS存储空间，从它的增长速率可以预估其使用情况，及时合理规划，安排扩容；还可以通过历史数据，看扩容前后和优化前后的效果对比。以上就是需要监控的四个原因。Watcher监控系统的起源初期去哪儿网也是使用大众监控工具cacti，cacti有丰富的第三方插件，当时也做到了监控覆盖率%。但随着业务发展，日益增长的指标量，cacti在性能上、扩展性上以及用户的使用效率方面就有些无法支撑，归根结底是因为cacti存在一些问题。首先cacti一个致命问题是单点，如果出现问题，并且修复时间较长的话，那么相当于那一段时间监控系统是不可用的，这时出现故障系统就无法及时报警。再者，cacti无法横向扩展。一个机器的存储空间是一定的，当数据越来越大时不得不通过压缩数据换取空间，但这样会导致历史数据不准确。并且cacti的监控可视化比较差，对外也没有提供API接口，所以很难基于它做二次开发。因为它不支持横向扩展，所以它没有办法支撑所有的业务线，所以去哪儿网从年底着手做新的监控系统。基于在使用cacti过程中遇到的一些问题，从应用的需求出发，设定了新的目标。新的监控系统一定要可靠、高可用、易扩容，而且一定要加强数据准确性和监控可视化。基于该需求，选型时主要考虑了以下几种：OpenTSDB、InfluxDB和Graphite。OpenTSDB是基于hbase做存储的，可以把所有的指标、所有的点存下来，但启动成本较高，不适合一个机房做一套；并且使用OpenTSDB需要Hadoop的运维经验，对于当时来说没有足够的掌控力觉得比较危险。至于当时的InfluxDB，远没有现在这么完备、活跃，模拟了监控数据后一个select*就搞挂了。后来经过豆瓣洪教授推荐和内部测试后最终选定Graphite。Graphite的优势在于它有强大的数据采集，友好的RenderAPI，还支持丰富的函数获取图片或数据，存储上使用whisper文件，结构简单易运维，最重要的是它是分布式的，它的设计完全scaleout，每一层都可以横向扩展。最终，去哪儿网基于Graphite，及它周边比较活跃的可视化工具Grafana和Nagios，进行二次开发后，形成了监控系统Watcher。Graphite的组件主要由carbon、whisper和graphite-api三部分组成。Carbon负责接收数据，用非常简单的文本协议，因为够简单，所以有很多现成的插件。Whisper是将收到的数据存储成whisper文件。whisper文件类似于cacti的rrd文件，固定大小，容易运维。Graphite-api支持RestfulURL获取图片或者数据，URL中还支持带各种有用的函数。它们之间的关系如下图所示：什么是Watcher监控系统整个Watcher的数据走向如下图所示：图中左侧部分是数据采集。Linux机器上部署collectd用来收集基础监控数据，windows机器上部署SSCServ，这些都是graphite周边工具链，业务指标收集用去哪儿网开发的QmonitorServer，也可以程序主动push数据，采集数据门槛较低，一条nc命令也是可以打监控数据的。中间就是整个watcher后端的集群，接收数据并存储。然后就是数据展示以及报警，dashboard是数据展示部分，checker+nagios做报警，上图代表了整个Watcher的集群，那单个的集群是什么样的架构呢？如上图所示，第一层的carbonrelay可以是多台的服务器做一个负载均衡，对外提供一个地址，功能是向下一层转发数据，这一层可以横向扩展。发给第二层relay通过一致性hash这样保证指标每次是打到同一台机器上，并设置把数据打两份，做一个数据冗余，这样一台机器挂了也不会影响服务，下面一层的carbonrelay接收到数据后发给carboncache，然后转成whisper文件写入磁盘，第二层relay也是可以横向扩展的，如果存储不够加机器就可以了。另一端通过graphite-api取数据返回给用户。这就是一个典型的线上集群架构。Watcher在去哪儿的应用这里按照监控的分类来说。首先是系统级别的监控，像机器的load、CPU、网卡流量等指标通过装机自动部署agent，采集完数据上报给Watcher，展示在dashboard上支持多维度，定义了很多监控模板。报警可以根据机器的属性，比如机器名、类型、系统、机架等等这些去定制规则，然后自动匹配。系统级别监控和报警都是全自动的。业务级别的监控报警，像接口的响应时间、调用次数、端口北京治疗白癜风哪间医院权威白癜风哪家医院看的好
