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