首页 >民生法规

APMCon201758集团龚诚构建立体

2018-10-27 20:21:03 | 来源: 民生法规

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 支持模板和模板的继承。这么多服务器的监控调整起来是很麻烦的,所以我们要求监控的模型一定要针对集群进行管理。监控策略绑定在集群层面上,不需要绑定到某一个机器,调整机器的时候可以不需要调整监控模板,极大的简化了监控信息的维护

APMCon201758集团龚诚构建立体

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 异常查看:方便查看当前有哪些异常,以及我接收告警的异常有哪些,这个功能方便大家快速的知道我负责的系统是否有问题。

猜你喜欢