导语
6月23日，1号店运维架构师龚德鑫在GITC全球互联网技术大会上发表了题为《如何打造一个高效智能的监控系统》的演讲，介绍了1号店是如何做到小投入、大产出以及如何解决监控工作中遇到的痛点问题的。
演讲嘉宾介绍
1号店
作为互联网公司，业务的发展始终是离不开技术的支持。技术的组成架构就好比汽车，由成千上万个零部件组合而成。零件之间良好运作，车子才能健康稳定的行驶。如果零部件发生了故障，这时候可能就会导致车子无法正常行驶，甚至可能产生车祸。而监控，需要做到全方位的监控。在任何一个环节出现了问题，都能第一时间发现，并及时的处理。这样才能使业务健康、稳定的发展。
实现自动化监控 事半功倍
全方位监控，需要明确监控目标。基础设施层面，目标有网络设备、存储设备、物理机、虚拟机和负载均衡等。应用服务层面，有服务代理软件、消息中间件以及数据库、缓存和各种应用软件。在业务层面，需要监控的有各式各样的业务数据。
前两者的监控，可以通过一些有效的工具进行监控，想要做到小投入，可以使用当下比较流行的开源软件，像Zabbix、Nagios和Open-falcon。
下面介绍一下1号店是如何实现自动化监控，从而提高工作效率的。
做到自动化的前提，是需要制定一些标准化的监控模板。根据设备的不同，有服务器设备、交换机设备和负载均衡设备这些定制好的模板。应用模板也是各自不同，Web Server的，数据库的，缓存的。有了这些模板，结合API，在服务器部署上线的时候系统就可以自动识别并分配相应的模板。
自动化部署的过程如下：
一台服务器的生命周期分为五个部分，装机、空闲期、服务器、维护期、下架。装机的时候可以通过自动化装机系统进行监控软件的安装，通过自动部署系统部署一些配置软件，这时候它是处于空闲期状态，我们会添加一个默认模板。这个模板主要就是一个ping，实时探测早期是不是连通。空闲期到服务期的时候，获取相应的应用模板进行添加，系统自动进行添加。服务期到维护期的时候，这时候就需要禁用相应的模板，反之再开启相应的模板，维护期到空闲期，我们会把这些应用模板统统删除，只保留一个默认模板，保持一个ping。最后维护期到下架的时候，删除所有的模板。
在这样一个生命周期中，系统都是完全自动化的进行监控的部署和变更工作，很大程度上减少了人工部署造成的错误的风险，同时也提高了工作效率。
1号店作为电商公司，以下四个数据是比较核心的业务数据，订单、支付、库存和用户数。如何有效对这些数据进行监控？通过业务研发团队提供给我们的API或者是SQL，开发一些开发脚本和趋势图，很快可以完成这些工作，但是会发现，业务的监控需求远不止如此，因为隔三差五就会有一些业务团队需要添加一个新的监控指标。
还有一种情况就是业务发生改变了，比如SQL字段发生了变化或者API结构发生了变化，也要进行相应的更改。如果没有及时的更改，这时候数据出现问题，没有及时报警出来，工作就会非常的被动。于是，我们就在思考：有没有这样一个系统，有没有一劳永逸的方式，既让我们摆脱繁琐的工作，又让我们的业务监控的需求得到有效的满足？答案肯定是有的。
业务健康监控系统 一劳永逸
分析以往的监控需求可以归纳为三个步骤：定义监控指标对指标进行数据采集，设置采集方式，最后就是添加相应的报警。于是我们就提供这样一个平台，让业务研发团队自行进行指标设置、数据采集、报警规则设置，在1号店叫做业务健康监控系统。
首先开发人员在界面上可以进行指标设置、数据采集设置以及报警规则配置，传到数据库中，数据采集器发现了这个指标，就可以进行相应的数据采集。数据来源分为DB的数据、日志的数据和接口的数据。如果以上三种方式满足不了，也提供相应的API让业务系统通过API的形式将这些数据推送给我们。有了数据采集，就需要进行相应的告警规则的判断。当它触发到报警阈值，就通过事件API进行告警，告警到事件告警系统中。然后通过语音、手机短信、邮件的方式，还有自动拨打电话的方式，通过各种方式告警出来。
报警规则支持多样化的，持续出发阈值、同环比上升、同环比下降，这样使告警更加精确。也可以通过不同时间段，设置不同的告警阈值，支持多条告警阈值。这样的方式是由于业务数据都是随着时间的变化而变化的，使告警更加灵活。有了这样系统，完全让业务监控需求掌握在研发人员自身的手里，一旦发生业务变更，他们可以第一时间通过这个平台进行更改。
利用日志发现根源问题
系统数据、应用数据和业务数据，如果监控出来有问题，大多是现象告警。比如服务器负载高了，或者订单下降，只能看到这些表现，不知道根源是什么。因此要针对根源的数据做有效的监控。哪些能体现根源？答案就是日志。
日志是我们的好帮手，日志可以体现系统的健康状态，通过日志可以分析到系统请求响应时间变长了，可能有些服务挂掉了，或者有些集群有机器挂掉了，或者是发现了潜在的问题，比如通过日志监测到异常数飚高，也许是程序层面出现了bug，最后它可以定位事故的根源，可以通过检测DB的数据，如果DB连不上，肯定就是造成这个事故的根源。
对日志进行分析，前提条件是进行有效的日志采集。要做到采集的前提，就是要做到日志规范化。日志规范怎么做？首先从路径着手，不同类型的日志，比方说应用日志、访问日志，存放的路径存放的目录是要固定的，其次是日志文件名称也要固定。然后是格式，日志需要展示哪些字段，以及日志字段的排序顺序。这些都需要有一个合理的规范。然后是时间格式，不能随意乱写，要有个固定的格式。还有就是日志等级，然后就是内容，规定不能出现一些敏感的内容，比如说用户的个人信息。
日志有两大类。应用日志通过自研的LogAgent进行采集。为什么用LogAgent？之前我们也用过LogStage，日志量大的话会导致服务器负载飚高，很多日志无法采集。后来我们就决定用C开发了这一套LogAgent，性能是更优的，也不会出现日志丢失。采集到了日志放到Flume集群中传输到Kafka。
访问日志通过Rsyslog采集，然后到Backend，也是我们自研的，可以进行日志补全。也是到Kafka，出来是两条路径，一个是到ES，然后到Kibana做展示，一条是到Storm，到Dashbord做统计，放到大屏监控上。
告警系统形成规范
有了数据的采集，发生问题如何及时的定位？这时候事件告警就派上用场了。我们之前的事件告警系统发现的内容都是非常的乱，有的内容分不清报警来源，分不清数据类型，有的内容只报了IP负载异常，而根本不知道这个IP是服务器IP还是交换机IP，又要重新排查问题。报警时常发生错报和漏报的现象，因为很多调用方调用监控，都是将参数写死在代码里，以至于发生了人员变动的时候，告警还是发给之前的人员，导致现在负责人无法收到告警，甚至有些离职的人员还能收到告警。
一旦发生线上事故，报警量非常巨大，也就是经常说的报警风暴，你无法看清是什么导致的告警，无法合理的聚合、归纳，排查问题基本靠肉眼，难以实现智能定位。原因就是之前的事件告警系统没有形成规范，没有统一的标准，导致出现以上种种现象。
因此事件告警必须有合理的规范和标准，使内容清晰，责任明确，易于分析，这样才能进一步实现智能分析。要做到标准化事件告警，首先规范来源，预先规范好使用方、调用方，即使出现人员变更的情况，可以结合CMDB的数据避免一些错报漏报的现象。其次定义好数据类型，什么样的数据报什么样的数据类型，业务数据、性能数据、系统数据，以便于后续的分析工作。然后划分事件等级，因为有些告警是日常的告警，只要通知相关的负责人处理就好了。有些告警比较重大，就要把这个等级提高，进行及时的处理。最后就是统一API接入方式，任何调用方都要按照指定的方式接入。有了前四项的保障才能实现后续的智能分析。
智能化处理告警
智能怎么做？简单归纳为四点，去重、屏蔽、聚合以及收敛。去重可以将相同来源相同内容的告警，归纳为一条，底层做一个数据累加。屏蔽就是消除已知变更的报警，就是机器可能现在正在重启或者正在发布，这时候产生的告警是完全可以屏蔽掉的。还有就是聚合相同应用的告警，相同应用的报警可以聚合在一条里。
收敛的模型有两种模式。从顶端开始如果探测到应用服务。应用不可用，可以通过探测发现现在的页面请求返回的内容有异常，继续往下探测，是否有Web Server层的不可用，或者服务代理挂掉了，这样就可以屏蔽三个告警。继续往下探测，发现是否有系统层面的不可用，可以通过ping的虚拟机，再往下，是否交换机出现了问题，这样自上而下的进行层层屏蔽，最后收敛到故障根源。就是系统收敛的模式。
另一种模式可以通过服务层，软件不可用或者是SOA服务出现了异常，继续向下探测，是否发生了Cache或者DB的不可用。这样层层收敛，就是应用收敛的模式。
这两个收敛模型的前提是，它们不需要合理的依赖关系，比如服务器是放在哪台交换机上，这个信息在CMDB都是存在的。然后，服务的依赖也是事先要有的，比如两个服务之间有什么关系，服务调用的是哪个DB哪个Cache等等。
实现智能化订单监控
订单是1号店的业务中的重中之重，如果它非正常下跌，肯定是系统层面出现了问题。因此对它的监控尤为重要。它不应该出现漏报，也要尽可能的减少误报，1号店做了不同策略的监控，历史记录的同比、同时期的环比、不同时段不同阈值，以及深跌、微跌双重监控。有了这个模型之后，表现效果非常好。但是随着季节的变化，还有运营活动的不确定因素，后来它误报增多了，甚至还有漏报的现象。分析原因就是监控对象是存在问题的，我们只是根据历史的数据进行监控，它的报警阈值是写死的，无法随着订单的变化而变化，不够智能。
要做到智能化的订单监控，首先取样要将大促节日分开取样，历史值也是取历史上的前N天，M个统计样点，然后进行处理。会把一个异常的订单，异常的点给替掉。有了历史数据点，计算预测值。基于现在比较通用的ARIMA模型，进行时时刻刻的订单预测。有了这个预测值就可以算出一个基准线，基准线通过同期样本点加上现在的预测值，就可以求出一个平均值得利用数学正态分布的模型，算出它的基准线。基准线就是符合在三个标准差。
这样的好处就是，基准线是能够实时随着订单的变化而变化的，也就是它的报警阈值可以动态变化。之后就可以拿当前值跟基准线进行对比。小于基准线并且小于统计值的话，就可以报警。
以上图为例，紫色的线是当前订单，绿色的线是算出来的基准线。当紫色线低于基准线的时候，同时它也比之前同期样点要小，这时候就可以进行报警。这个模型就是比较智能的，从而减少了很多的误报，效果非常显著。
快速处理故障
做监控的目的就是保证系统的稳定，出现故障就要及时处理。1号店的事故处理中心，主要有两大功能，一个是信息平台，它会将时时刻刻有关故障的相关信息同步到这个平台，二是有一些便捷的工具，方便故障恢复的工作。
首先有一个信息展示时间轴，主要来自于监控告警的前半个小时的内容，还有变更记录，看看有没有相关的发布相关的变更。有了这样的数据来源，通过监控平台可以将智能定位到的告警，主动发布到这个信息时间轴上，方便相关人员查看。同时相关人员也可以将一些疑似定位到跟这个问题相关的告警，通过手动方式发布到这个时间轴上。发现这个问题，可以以邮件的方式发送给相关的人。不在电脑旁的同事，可以通过手机端实时查看这个动态。
定位到了事故之后就需要进行事故处理，可以通过配置发布进行代码的回滚，然后可以通过工单系统进行服务器的重启，全程都有过程的记录，方便后续的分析和统计。
事故处理的过程是什么样的？首先事故发生，当开启这个事故，所有的告警信息和与之相关的信息，发布信息，都会汇总到信息平台，方便决策处理事故处理，然后重启、回滚、扩容，最后关闭。所有的过程都记录下来，便于事故分析和事故记录工作，方便以后相关的人员查阅，让他们引以为戒，出现了这次事故，下次就尽量避免。
监控的整体架构如下图：
下面两层都是数据采集的工作，有Zabbix采集的系统数据，服务数据可以通过SOA进行数据采集，到核心层有监控管理，监控管理是监控部署的相关操作，监控设置。监控服务有几大数据的汇总，然后就到事故处理中心、告警系统，最终有一个数据展示。