APMCon 2017｜58集团龚诚：构建立体化的监控体系—58集团监控实践
【转载】作者:转载
【文章简介】
APMCon 2017|58集团龚诚：构建立体化的监控体系—58集团监控实践 ... ......
中国应用性能管理行业盛宴—2017中国应用性能管理大会(简称APMCon 2017)于8月10日至11日在北京新云南皇冠假日酒店隆重召开。本届APMCon是由听云、极客邦和InfoQ联合主办，作为国内APM领域最具影响力的技术大会，本次大会以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
58集团技术工程平台群高级技术经理—龚诚于APMCon 2017智能运维专场发表了题为《构建立体化的监控体系-58集团监控实践》的演讲，现场解读了如何将运维数据进行量化和可视化，以及58集团在监控方面如何快速的构建起立体化的监控体系。
以下为演讲实录：
龚诚：首先欢迎大家，我今天演讲的题目是“构建立体化的监控体系-58集团监控实践”，主要讲一下我们58集团是如何在最近一年多时间内，从监控做的不是很好的状态，发展成为相对来说比较完善的状态的。
我们的监控工作其实可以划分为四个阶段：第一阶段，如何快速获得监控收益，最开始的时候监控的情况不是很好，所以要快速的实现基本的监控功能;第二阶段，构建立体化的监控体系，各个端、各个层面的监控都要比较完整和完善;第三阶段，提升监控系统用户体验，基本的功能都有了，怎么能让大家用的更爽呢，就是要提升用户体验;第四阶段，智能化监控和发送告警。
那么，我们为什么要做监控?监控的定位和目标是什么呢?
l 监控系统是线上服务的守护神，是我们整个网站稳定性的一个重要的保障。
l 监控系统是技术人员的眼睛，帮助我们快速发现异常和排查这些故障。
l 监控系统可以对运维的数据进行量化和可视化，便于对网站进行优化。
58集团监控系统的发展经过了如下几个阶段：
一、如何快速获得监控收益
这里先说下这些监控的痛点，我们最初面对的也是这些问题：
l 监控系统数量非常多。由于各种历史原因导致每个机房的网络运维、系统运维、应用运维、各个研发部门都有各自的监控系统。
l 告警数量非常多。每天运维人员可能要接收几百条的短信告警，这么大的告警数量对运维人员造成很多干扰。
l 告警覆盖度不够，很多故障发现不了。
l 监控添加起来非常繁琐，操作步骤过于复杂。
l 难以辅助定位故障，不能通过告警信息和监控数据快速定位故障。
l 监控系统运行情况未知，没有运营数据的分析。
根据这些痛点我们整理了一下对于监控的需求，主要分为两点：
1、监控业务模型
l 针对集群进行监控。早期的很多开源监控系统是服务器级别的监控，我们负责运维58集团下属的很多网站，包括58同城、赶集网、中华英才网、安居客、转转等网站，我们的服务器数量是非常多的，为了管理方便，一定要以集群维度进行监控的管理。
l 支持模板和模板的继承。这么多服务器的监控调整起来是很麻烦的，所以我们要求监控的模型一定要针对集群进行管理。监控策略绑定在集群层面上，不需要绑定到某一个机器，调整机器的时候可以不需要调整监控模板，极大的简化了监控信息的维护。
l 模板中包含多条监控策略。对于监控肯定有很多共同的需求，可以把这些需求都写在通用的模板里，然后用集群自己个性化的模板继承共用的父模板，这样既实现了大家共同的需求，每个人也不需要重复配置，也可以添加自己服务特殊的监控策略，这样很好的兼顾了通用性和个性化。
l 支持告警组。在一个公司里总会有人员的变更，为了方便告警管理，可以将告警发送给告警组，告警组里可以配置用户，用户可以随时进行调整，有效减少了监控的维护代价。
2、对监控系统的要求
l 高稳定性和分布式系统。监控系统是用来保障网站稳定性的，所以它自身的稳定性就必须要高，且具有很强的容错能力。
l 性能强大，支持横向可扩展，无性能瓶颈。当我们的服务器数量和业务规模增加的时候，可以简单通过横向扩展各模块的方式实现容量的提升，不需要对系统进行大规模的升级改造。
l 单个模块逻辑简单，方便二次开发。为了更好的支持我们的业务，任何一个监控系统都需要根据我们自己的业务需求做一些定制化的开发，那么它的二次开发是否方便就非常重要了。
基于前面提到的这几点，为了减少整个监控系统的开发周期，我们以现在业界比较流行的open-falcon为基础进行二次开发。
在第一阶段的工作中，首先我们将监控切换到open-falcon，它解决了以下三个主要问题：
l 解决部分服务器无监控的问题，把很多套监控整合为一套，把所有系统层的监控、应用层的监控、网络层的监控完全整合起来，保证了服务器级别的监控覆盖率。
l 解决告警发送数量过多的问题，主要从两个方面：open-falcon本身就有比较好的告警数量控制的机制，可以支持定义告警最多发送次数，对异常做告警分级，对不同的告警以不同的方式来发送;也会针对不同重要性的异常进行判断，初期只针对最核心的集群发告警。
l 解决了告警接收人的问题。在老的系统里，很多告警接收人由于业务的变化，人员的变化已经不是很准确了，这一块我们也重新进行了梳理和配置。
其次，我们开发了“快速添加监控”的功能。在满足基本监控需求后，技术人员对于每个集群会有更多更个性化的监控需求。大家用过open-falcon可能有些体会，功能非常强大，但是添加监控的流程还是很复杂的。首先要创建一个集群，然后在集群里绑定一些服务器，再创建一个监控模板，然后在模板里创建很多监控策略，再创建一个告警组，告警组里加告警接收人，再把监控模板跟告警组关联起来，最后把集群和模板关联起来。基本上要通过十几个操作才能把一个集群的监控添加好，这个过程是比较复杂的，也是容易出错的。所以我们开发了快速添加监控的功能，很好的解决了上述问题：
l 便于技术人员快速添加监控，提升了易用性和监控添加效率。
l 在一个页面添加集群名、机器列表、监控策略、告警接收人即完成告警添加。
l 可以自定义集群、监控模板、告警接收人。
l 对关键的集群都添加了系统层和应用层的监控，保障了关键服务的稳定性。
接下来，我们实现了对集群自动添加监控。如果依靠大量的技术人员依靠人工来添加监控功能的话，必然带来很多工作量，而且监控的覆盖度也无法保证，所以接下来做了自动的添加系统监控。具体做法如下：
l 从CMDB同步信息，为各集群自动添加基础监控。
l 所有集群的模板继承公共的系统监控模板。我们会根据共同的需求整理一个公共的模板，基础的监控策略都配置在这个公共模板中，每个集群的监控模板都继承该公共模板。
l 告警信息发送给各集群对应的运维和研发负责人。
l 从自动部署系统同步端口号添加端口监控。
l 可自定义监控指标。在本集群的监控模板中可以添加很多自定义的监控指标，比如服务QPS、订单量、用户量等只要能采集到的指标都可以进行监控。
另外我们在加强功能、提升易用性方面也做了很多工作，对于监控来说最关键的无非是以下几点：
l 监控配置：方便添加常用监控。
l 数据查看：便于查看监控数据、监控视图、监控墙。
l 告警查看：提供了多种告警的接收方式包括邮件、微信、短信和语音。
l 异常查看：方便查看当前有哪些异常，以及我接收告警的异常有哪些，这个功能方便大家快速的知道我负责的系统是否有问题。
上面这些工作做好了之后，在监控方面已经基本上能够满足大家的需求，为了让系统起到更大的作用，也更新了帮助文档协助大家更好的使用我们的系统，另外也会在公司的技术开放日，以及去各个部门宣讲我们的监控系统。
二、构建立体化的监控体系
通过上图我们可以看到网站的通用架构。首先在机房外部有域名解析，它会让动态请求直接到机房进行访问，静态请求到CDN访问，机房内部有网络出口以及四层和七层的负载均衡设备，再到nginx和业务集群上。刚才做的监控工作主要在集群或者服务器维度，对于整个用户端、机房出口端及四层、七层负载均衡设备上做的相对比较少，我们这个阶段就是主要完成这些工作。
纵向构建立体化的监控体系
上图右侧是集群和服务器维度的监控，自底向上是网络层、服务器层、系统层、应用层和业务层监控。对于网络层监控我们最关心的是网络设备有没有宕机、资源使用率和流量是否正常，以及内网和专线的服务质量等;在服务器层关心机器是否宕机、是否无法登陆或者是否有硬件故障;系统层主要关注资源使用率，例如CPU、内存、磁盘、网络等指标;应用层与应用程序更加相关了，比如端口、进程、接口状态、服务QPS等所有与应用层程序相关的指标都可以在这里进行监控;业务层是与具体的某项业务更加相关了，比如说我是电商类型的网站，那么对于订单量、交易量就会非常关注。
横向构建立体化的监控体系
再来看横向的监控，前面我们提到了比较粗略的通用网站架构图，我们把这些信息略微细化一些，从左到右，首先是在机房外部对域名的解析。由于用户处于一个比较复杂的公网环境当中，所以用户访问过程中会遇到很多如DNS劫持、链路劫持等问题，导致无法访问正常。对于CDN节点来说，也会出现一些跨运营商或者跨区域调度造成的访问速度较慢问题。对于我们机房的网络出口，VIP是否正常也是需要我们监控的。在四层负载均衡设备上我们比较关心流量的变化，在七层负载均衡服务上比较关心域名、集群维度的错误率(状态码)、响应时间等指标的变化。再往右看，业务集群的监控跟纵向监控更加相关了，关注集群和服务器的维度。
基于上述的分析，我们在用户端监控对于一些重点页面的关键指标进行了监控，包括页面的首屏时间、全部加载时间、可用性等。这些指标能够帮助我们比较好的描述网站的用户体验是怎么样的。对于DNS劫持、链路劫持、页面访问较慢、访问错误等都进行了监控。
在机房网络出口端，首先会对VIP是否存活做监控，也会在业务层上针对关键页面或者关键接口从机房出口VIP上进行探测，这样可以比较清楚的知道整个集群服务所提供的服务状态是如何的。因为是直接从机房网络出口进行探测的，所以它不会受到公网服务质量的影响，能够比较全面的评价从流量接入端到后端业务集群的服务质量。另外也会对集群中的每台服务器做页面和接口的监控，便于发现部分服务器的异常。
在流量接入端的网络设备上可以监控流量变化，以及是否受到攻击。另外在Nginx上可以针对域名维度、集群维度进行监控，评价域名和集群的可用性和响应时间。
在业务端集群，监控的维度是针对于单机和集群的。单机的监控更像刚才提到的纵向监控，从网络层、服务器层、系统层一直往上，还有针对服务器的页面和接口监控。针对集群，一方面有通过机房的网络出口做的页面监控和接口监控，另一方面也会通过Nginx上的一些流量的变化看后端业务集群的运行状态，看它整体的可用性和响应时间。
所以简单的总结一下，构建立体化的监控体系是从纵向和横向两个维度来实现的。
立体化监控体系构建完之后还要在监控的核心功能上下功夫，比如监控的添加、数据的查看、监控数据视图、告警查看、提供更好的功能以方便我们快速发现故障、排查故障、解决故障。另外，我们也做了很多运营质量评估方面的工作，我们认为监控要做的一项比较重要的工作是使整个网站的运行信息透明化，原来没有监控的时候整个网站像一个黑盒子，哪个地方运行的好或不好、哪个地方是瓶颈我们都不清楚，通过监控系统可以把它由黑盒子变为白盒子，每部分的运行情况都清清楚楚，这样就知道哪部分出现的异常更多，哪部分是性能瓶颈，需要及时进行优化。我们运营质量评估分成了三个层次：
l 业务集群：在Nginx上看整个业务集群的服务质量怎么样。
l 机房网络出口端：看流量经过TGW，Nginx和业务集群的整个过程的服务质量。
l 用户端：以用户视角在公网环境看服务的质量。
三、提升监控系统的用户体验
监控的基本功能都可用后，完善的用户体验就成了我们的重要目标。刚才也提到了open-falcon本身添加监控是比较复杂的，我们发现用户在使用的时候也会觉得比较困惑，添加监控、管理监控总会出现一些错误的情况，怎么办呢?
简化监控业务模型
之前提到过，open-falcon的监控模型是相对比较复杂的，如下图所示：
所以我们就对监控的业务模型进行了简化，所有监控的配置项都是与服务树的节点也就是集群进行关联，集群是我们从CMDB里同步过来的，集群会关联服务器列表，集群也会关联唯一的监控模板，这个监控模板会继承公共的监控模板，就是说一些通用的监控项都已经在里面设置好了。另外我们把之前关联在监控模板上的告警接收人直接关联到集群上，这样的话对于一个集群的监控只需要关注这三点：服务器的列表、监控的模板和告警接收人。只要这三部分信息都设置正确了，那么这个监控的添加肯定是没有问题的，这样既满足了我们的需求又极大降低了复杂性。简化后的监控业务模型如下：
Web页面框架和服务树模型
我们在监控系统Web界面的展示上提供了基于服务树的展示模型。所谓服务树模型是将公司整个集团下属的事业群、业务线、集群按照一个树型的结构进行组织。当你想操作某一个业务线或者某个集群的时候，选择服务树里这个节点就可以对它进行操作了。
另外我们的监控系统除了包含开源的open-falcon之外还有很多自研的系统，这么多系统怎么样更好的进行整合呢?如何统一整体的用户体验、页面的风格以及交互方式呢?如果上述方面统一的话，在用户看来学习的代价就会很小、易用性就会很好。所以，我们使用了一个统一的web框架，用户操作的时候，首先通过服务树节点选择一个操作范围，然后通过菜单选择使用的功能，页面中就可以展示相关的业务信息了。这样就可以把用户使用监控系统的交互方式统一了。我们也对自研的监控相关系统做了整合，包括Nginx业务流量的监控、网络的监控、用户端监控、IDC出口以及运营质量数据等。
我们根据简化的监控业务模型开发了一套web的页面，如下图所示：
这个页面展示的是统一的web框架和服务树模型：左侧是树型的结构，根节点是58集团，下面是各个事业群，再下一级节点是业务线，再下一级节点是集群;页面上面是一排菜单，每一项是一个一级菜单，当把鼠标放上去的时候会看到二、三级菜单。在左侧的服务树上选择服务树节点相当于选择了一个业务的范围，也就是要操作的是这块业务;在上面的菜单中选择某个菜单就是选择某个功能，两者都选中后，右侧就会显示出相关的业务页面，用户就可以完成相关的数据查看和管理操作了。
监控信息的管理
刚才提到过，管理监控需要关注三部分信息：
l 告警接收人：这里可以看到配置了哪些告警组，包括出现异常时发送告警的告警组，以及告警升级后的告警组。
l 监控模板和监控策略：通过这里可以看到，集群对应的模板是继承了一个公共的父模板，在父模板里定义了一些像剩余磁盘空间、系统的负载、是否宕机等这些最基础、最重要的监控。另外，在这个集群的监控模板中可以根据它的需要去添加一些个性化的监控策略。
l 服务器的列表：在服务树里面搜索某一个集群，服务树上自然会把包含关健词的集群显示出来，选中这个集群直接可以看到这个集群的服务器列表。当集群中的服务器列表发生变化的时候，可以在这里增加机器或者删除机器，并且可以看到某台机器是不是被其他集群共用。
上述的信息对每个集群来说都自动添加了监控，只要维护好了每个集群的上述信息，就能够正常的告警了，通过这种方式极大的降低了监控的维护代价。
告警发送策略优化
我们在原来open-falcon的基础之上做的一点改进。我们对告警进行了分级，并且提供了多种方式发送告警，包括：邮件、微信、短信、语音，不同重要程度的告警采用不同的方式进行通知。
open-falcon在异常告警的发送次数控制上做的还是比较好的，它可以控制发送告警的最多次数，比如设置告警发送次数最多为3次，当告警发了3次之后就不会再发了，直到从异常中恢复了才发一条恢复正常的告警。我们来看一个场景，如果前3条告警由于运营商问题没有收到或者负责人当时正在忙什么事把这个告警忘记了，这个异常要持续几天甚至几十天，那么对网站稳定性有很大的威胁，所以我们增加了告警升级和告警提供功能。
比如说我们设置的连续3次异常的时候再告警，两次告警时间间隔5分钟，最多告警3次。我们结合上图看一下，蓝色的线是时间轴，底下的数字代表时间，绿色代表数据正常的点，红色代表数据异常的点，在前3分钟连续3次出现了异常，所以它发出了第一条黄色的告警，5分钟之后发送了第二条，又过了5分钟又发送了第三条告警。按照之前的策略，这个告警如果不去处理的话，可能未来几天甚至几十天都不会发任何告警，我们这里增加了一个策略，在最后一条告警发送完之后30分钟后如果异常还存在则会把告警升级，且使用更明显的方式提醒用户。另外如果说这个故障持续时间超过一天了，之后的每一天我们也会给再发告警提醒一次。
当前异常信息的查看
当前异常信息的查看也是监控系统中非常重要的一项功能，下图就是该功能的页面，这里可以通过服务树选择一个业务范围，选择查看整个公司的异常或者只查看某个业务线或者集群的异常。右侧还有“我的告警”选项，选中这个选项会看到所有与“我”相关的告警和异常，页面还可以根据设置自动刷新，这个功能对于运维值班和做系统巡检是非常有用的。
这个页面是展示的当前处于异常状态的告警，当它从异常状态恢复到正常之后这个信息就自动消失了。另外在这里也可以很方便的进行搜索，比如根据告警条件、异常类型甚至告警接收人进行搜索。
如下页面展示了最近的告警事件有哪些：
这个页面把每个告警事件作为一个圆圈展示出来，圆圈越大说明告警级别越高，颜色越深代表告警次数越多，而且把鼠标放到某个圆圈上的时候能够看到某一个告警的详情。因为服务有可能依赖于一些存储服务或依赖于别人的接口，所以当出现异常的时候，可以上来看一看是不是跟你相关的服务在这个时间附近也出现了异常，有可能因为它的异常引起我们服务的异常。
监控数据查看
监控数据的查看也是非常重要的一个功能，故障时对异常原因进行排查、做完系统优化后对比效果、规划系统容量等操作都会用到这个功能。
用户操作界面如下图所示：
用户在使用该功能的时候，首先在左侧服务树里选择事业群、业务线或者集群，在右侧会显示出来它对应节点下的机器列表，而且在上面可以对IP模式进行一定的搜索，通过右侧的常用指标选项可以快速选择我们平时常用的监控指标，比如概况、CPU、磁盘、IO等，这样就能够很方便的通过几次点击的方式看到一些常见的视图。当然高级搜索可以满足更加个性化的需求。点击看图按纽就能够看到相关的监控数据。
当然这些监控数据可能不只是今天看一下，有可能平时工作当中会常常查看的一些视图，可以在这里面点击生成视图按纽，生成视图并且收藏起来。那么下次直接在“我收藏的视图”中就可以快速查看监控视图了，我生成的视图也可以被其他用户收藏和查看。
监控墙
我们把核心数据放到监控墙中展示，可以很方便的看到网站运行中最重要的一些数据。
容量管理
通过监控系统采集的服务器的数据和业务相关的数据，也可以针对不同的容量、负载模型进行计算，得出每个集群、每个业务线相关的负载指数，通过雷达图可以展示各个分项指标，可以很好的规划容量，也可以在分配服务器的时候有效的控制服务器成本。
运营质量评估
在运营质量评估方面，我们可以针对业务集群维度、机房IDC出口维度、用户端维度进行评估。这个页面展示了集群的关键指标，可以看到某事业群下面的多个集群的响应时间。
我的监控
对于大家平时常用的功能，都可以在这个菜单内找到，比如我收藏的视图、我负责的异常、我订阅的告警、我的集群和我的模板等。如下是访问监控系统首页后默认展示的“我收藏的视图”页面：
四、智能化的监控和告警信息
告警信息的合并
l 同服务器告警合并。我们可以对同一个服务器的告警进行合并，因为如果一个服务器宕机的话这个机器上肯定有其他的告警，只需要告诉用户这个服务器宕机就可以了。
l 同集群告警合并。由于用户流量特别大或者程序出现某个bug，这个集群当中每一台服务器都会出现告警，如果同时发几十条告警也是一种干扰，所以我们对同一个集群的告警进行了合并，直接发送一条告警。
l 同网段的宕机合并告警。由于某个交换机出现了异常，肯定有同网络上的机器出现了大量的丢包告警消息，其实这些告警合并起来就可以推断出某个交换机网络设备出现了问题。
l 同根因的告警合并。当监控的覆盖度比较高的时候，对每一个层级都会有监控，如果一个集群出现问题就会在很多层级的监控告警体现出来，这些问题都是可以进行合并的。
告警信息优化
l 提供更多的告警方式：对异常告警进行分级，增加语音告警和微信告警。
l 告警信息丰富化：在微信告警中，可以展示更丰富的信息。除文字外增加了很多监控指标相关的图片，能够直观看出异常数据的变化趋势。另外也增加很多链接，可以快速的通过点击这些链接修改相关配置信息。
l 异常的根因分析：需要我们逐渐构建起运维的知识库推断出来异常的根源原因。
新的监控策略
l 数据的同比环比监控：可进行趋势异常变化的告警和数据对比展示。
l 数据的异常变化率监控：连续一段时间内数据出现突增和突降。
l 集群中异常机器比例监控：集群中超过一定比例的机器有问题才发告警。
l 组合条件的告警：多个监控指标都满足条件则告警。
l 容量监控：预测即将达到容量水位则告警。
故障自愈
l 服务器宕机自动处理：如果服务器宕机，自动重启服务器;如果服务器出现硬件故障可以通过服务器的机型、对网络的需求等信息自动分配备机。
l 磁盘空间不足自动处理：通过一些告警事件触发自动删除一些预定义目录的文件。
l 负载升高自动扩容：当集群负载升高，达到警戒值后自动调用部署管理系统和云平台，自动对系统做扩容。
l 流量自动调度：当某个机房或网段出现问题时，操作TGW和Nginx进行流量调度。
我今天分享的内容就是这些，谢谢大家!
QA：
问题：Nginx的日志监控是怎么做的?
龚诚：使用ELK将Nginx日志实时传输和计算，再把数据实时灌到open-falcon里，通过open-falcon做数据展示和告警。现在正在从ELK迁移到storm。
问题：对于关键业务的关键接口，这些接口监控是在Nginx日志里分析还是请求接口做的?
龚诚：两方面都有，我们会实时分析nginx日志，也会实时对接口发送请求进行监测。
问题：监控DNS劫持和用户打开页面体验好不好的监控是怎么做的?
龚诚：通过听云在全国各区域各运营商的探针采集数据，然后将原始数据拉回来自己做分析，再进行数据展示和告警。
问题：我想问怎么做压缩告警，因为我们的日志有可能发生大量的error，假如1分钟内有100个A错误、1个B错误，又有100个C错误，理想的状态是收到三条告警。现在我们是通过一个case来判断次数的，但是这个次数没有做智能压缩的，只能是一分钟收到多少条就压缩为一条，但是不能把不同的错误分级别发出来，您这一块是怎么做的?
龚诚：这个是具体实现层面上的事情，告警可以按照不同业务需求进行实现，需要具体问题具体分析。刚才你说的情况是根据错误的类型对告警数量进行合并，你可以每分钟对这些错误的数据按照错误类型进行合并，得到A错误100次、B错误1次、C错误100次，然后将这3个信息使用不同的监控指标推给监控系统，对不同的指标设置不同的告警策略和级别，就能够实现对不同错误类型做告警分级。
问题：是我们自己研发还是用第三方比较好，因为开源工具包括小米的还是其它都实现不了。
龚诚：要把自己的需求和开源系统较好的结合起来，开源监控系统实现的都是通用的模型和功能，自己的业务要选择一个好的方式和开源系统结合起来。跟自己业务和需求相关的部分，要自己控制这部分逻辑，把数据处理成标准格式后，再推给监控系统，使用开源的系统来解决。
