58集团监控业务实践：将网站运行信息透明化

作者介绍
龚诚，58集团技术工程平台部高级经理，硕士毕业于哈尔滨工业大学计算机应用专业。曾任职于百度、新浪微博等公司负责运维及自动化团队的技术和管理工作，在网站的稳定性建设、网站优化等方面有丰富的经验。监控系统是服务稳定性的重要保障，本文将分享58集团监控业务实践。总体工作思路是将网站运行信息透明化，按照各项工作的重要性分步骤构建起立体化的监控体系。首先解决稳定性问题，再解决网站优化和节约成本的问题，有利于在短期内快速取得收益。

主要内容如下：

• 监控系统的业务定位
• 监控系统的核心需求
• 监控系统的应用规模
• 如何在监控方面快速取得收益

业务定位  

监控业务的定位可以概括为：线上服务的守护神，是服务稳定性的重要保障。

1、监控系统是运维和研发人员的眼睛，可以快速发现和排查故障。

2、监控系统将运维数据进行量化和可视化，便于对网站优化。

核心需求  

监控业务的核心需求可以概括为：通知异常、发现故障、追查故障、预防故障、优化网站。

    1 .有效的告警（通知异常）

在监控系统发现异常后，通过告警信息通知相关负责人。这就要求告警的有效性，有效性体现为：发生故障时要发出告警；确定是需要处理的异常才发送告警；告警数量要控制在合理范围内，可以深入跟踪和处理，每天大量的告警和没有告警是一样的，不会引起重视；告警信息中明确说明异常的相关信息，通过告警可以明确知道出现了什么异常，情况有多严重；告警要根据重要性分级，使用不同方式通知异常，重要的告警使用语音送达，确保告警信息引起重视。

    2. 数据可视化（发现故障）

监控数据可视化有助于快速发现问题。在用户收到告警后可以快速查看到相关的监控数据变化趋势，从数据上分析、定位问题。可以在告警信息中加入链接，点击后直接跳转到相关的监控数据视图，这样能够减少查询监控数据的时间。另外，对于用户的个性化数据可视化需求，可以添加自定义的监控视图，将自己关注的指标添加进去。对于网站的重点服务和核心监控指标，将监控视图配置为“监控墙”进行展示，便于日常进行巡检和发现问题。

    3.    辅助排查故障（追查故障）

为了方便排查故障，除了基本的监控数据可视化外，还需要提供一系列功能对异常告警进行展示。监控系统中可以展示所有当前存在的异常，用户访问系统直接看到与自己负责服务相关的异常。用户还可以按照时间序列查看最近处于异常状态的事件，便于对关联的异常进行分析，推断故障根源原因。

为了方便了解网站在全局的运行状态，用户可以在全局视图中看到各模块的运行状态和模块之间的调用状态，当某部分出现问题时能够用突出的颜色标识出来。也可以定义服务之间的依赖关系，根据各服务之间的依赖关系自动分析故障的根源原因。

    4.    对告警做运营分析（预防故障）

为了预防故障，需要提供一系列功能对监控运营状况做数据分析。

运营分析有的服务于监控系统的运营人员，以便了解监控系统的运行和使用情况，发现问题及时进行内部调整和推动相关部门进行优化。例如：每天发送的告警电话、告警短信、告警邮件等的发送次数，及近期变化趋势。每天出现次数为TOP 10的异常类型、异常服务、异常集群、告警接收人、异常服务器等。

运营分析也服务于研发和运维部门的负责人。例如：相关负责人可以在web查看自己负责范围的异常事件信息，也可以通过邮件报表查看自己负责服务的告警次数和告警持续时间等。

    5.    网站系统透明化（优化网站）

通过所有服务必须包含的基础框架采集服务之间的调用链，构建全局系统架构视图。通过全局视图，用户可以看到各模块的运行状态和模块之间的调用状态，当某部分出现问题时能够用突出的颜色标识出来。也可以定义服务之间的依赖关系，根据各服务之间的依赖关系自动分析故障的根源原因。另外，还能够及时发现系统内部的不合理依赖，对架构不合理情况进行改造。

应用规模

    1.    覆盖围范

覆盖58集团下网站：58同城、赶集网、中华英才网、安居客，转转。

覆盖网络、主机、系统、应用、业务等多个层级。

覆盖用户端、IDC出口、流量接入端、IDC内部服务端。

    2.    数据规模

我们的监控系统中通过自动和人工添加的方式配置了超过万台服务器和网络设备，3000余个集群，近3000个监控模板，300余万个监控指标，每天实时处理的数据量超过2T。

工作思路  

如果要提升网站的稳定性、对网站进行优化，那么监控是一个很好的切入点。我们的总体思路是按照各项工作的重要性分步骤构建起立体化的监控体系。首先解决稳定性问题，再解决网站优化和节约成本的问题，短期内快速取得收益。下面是一些具体步骤。

    1.    服务端基础监控

为了保证监控的覆盖度，首先要覆盖所有服务器的基础监控，例如：服务器是否宕机、系统资源的使用率是否过高等。由于监控的添加也是需要较大的工作量，很多运维和开发人员在此方面投入的精力有限，出现问题不能及时发现。

为了解决该问题，我们从CMDB系统同步了集群中包含的服务器、集群负责人等信息，在监控系统中配置默认模板、自动添加了基础的系统监控。这样，当出现服务器宕机、假死、硬件故障、系统资源使用过高、端口不通、JVM状态异常等情况，监控系统会发送告警给对应集群的负责人。通过这种方式，既不需要大量的人工配置，也能够快速提升服务器层面的监控覆盖率。

另外我们也积极推进应用层监控和业务层监控的添加，在监控系统上提供了快速添加监控的功能，保证用户能够以较小的代价方便添加监控。

    2.    流量接入端监控

在完成服务器的基础监控后，需要对服务是否正常进行监控。由于后端业务集群的数量非常多，逐个去添加服务的监控需要了解更多的业务信息，一般来说需要投入更多的时间和精力。

为了在短时间内解决应用服务的监控问题，我们首先保证所有流量都经过nginx集群进行分发，通过elk实时收集nginx的日志，然后按照域名和后端集群维度分别获取错误率和响应时间。域名维度的监控更关注返回给用户的错误率和响应时间；后端集群维度更关注后端集群出现的错误率和响应时间。

通过这种方式，我们可以对各业务集群的状况进行监控，故障时能快速缩小排查的范围。

    3.    页面监控

通过前面的工作，已经能够对服务器级别和重要的后端集群进行监控了，一般较大的故障已经能够及时发现了。

为了更好的发现一些重要的异常，我们还通过IDC出口的VIP对页面进行监控，当IDC的出口链路故障或者后端集群出现故障时能够及时发现。该监控发现的故障是重要性较高的故障，当监控发现异常时，外部用户已经能够发现访问异常。通过这些监控数据也能够综合评估页面的可用性和响应时间。

    4.    网络监控

在网络监控上还需要对VIP的可用性、流量等进行监控，确保及时发现链路的异常。还要对各IDC之间的专线和IDC内部的网络进行监控，及时发现问题、进行优化。

    5.    数据可视化

经过前面几步，监控的覆盖率已经比较高了，系统的异常已经基本都可以发现。那么为了更方便的查看监控数据、排查异常，需要将监控和告警的数据进行可视化。

监控数据可视化：可以方便的通过服务器的IP、集群名等方式快速查看相关服务器的监控指标变化趋势，从而发现故障原因。另外，为了方便查看常用的监控视图，还可以定制监控视图和监控墙，方便日常进行巡检。

告警数据的可视化：为了方便用户查看自己负责服务的异常，提供了多种角色视图及搜索功能便于查看。为了方便排查相关服务的异常，还提供了按照时间轴组织的监控异常事件展示功能，在某个服务的故障时间点附近可能有依赖服务的异常告警，从而方便用户快速定位故障的根源原因。

    6.    用户端监控

由于用户处于各个地域、各个运营商中，用户的访问速度和用户体验受公网的影响，与local DNS的解析、CDN的流量调度、CDN节点状态、链路劫持等都有很大的关系。为了评估用户真正的用户体验、及用户网络的异常，需要通过第三方的APM或页面中的js收集数据在用户端进行监控。

    7.    运营分析

有了前面的监控数据，能够从多层次、多维度进行运营质量分析，例如：

• 告警统计分析：TOP N的异常类型、服务、集群、服务器、告警接收人等。
• 后端集群分析：可用性、响应时间、各种错误的比例。页面的关键指标变化：可用性、首屏时间、加载时间、加载字节数等。
• 动态页面的访问分析：在IDC出口和用户端的对比可用性和响应时间。
• 用户端数据分析：对用户端的劫持和访问较慢问题进行分析。

    8.    容量管理

容量管理也是与监控业务相关联的，可以先从服务器负载开始做容量管理。

通过监控数据和服务器负载计算模型可以计算各事业群、业务线、集群的负载情况。从而简单、有效的评估负载情况，据此做服务器采购预算和分配，节约成本。

在此基础上，可以对服务集群的极限容量进行测试和评估，做性能瓶颈分析、容量预警、弹性伸缩等。

最后我们总结一下，如果面对一个不是很稳定的站点，那么从何入手呢？

首先可以先将监控搭建、完善起来，保证将重要的告警发送出来、且控制告警的数量。对关键服务的监控包括通过nginx的日志对后端集群进行监控，在IDC的出口对页面进行监控。

然后通过人工或自动化的方式逐渐提高监控的覆盖率，辅助以监控数据可视化、监控异常排查工具等方式缩短排查故障的时间。在保证了服务端比较稳定的基础上，再对用户端的访问情况进行监控。有了这么多的监控数据，就可以做一些运营分析，及时发现相关的问题、进行优化。

最后可以基于监控数据深入的做容量的管理，提升资源使用率、降低成本等。

QA环节

Q1：银行业务系统如何监控，用哪些技术个软件？

A1：银行业务系统的监控思路和互联网系统的思路是一致的。关键还是看：希望发现哪些异常？这些异常有哪些特征？如何采集这些特征？如何判断异常？在具体的技术和实现上都是类似的。可以自己开发、也可以选择开源软件，还可以购买一些厂商的产品。

Q2：你们的精细化监控是如何实现？需要把监控嵌入到业务上吗，比如：监控业务异常（进程还在，程序报致命异常）是如何实现？

A2：我们希望采用的是尽可能通用、尽可能对业务代码侵入少的方式进行监控，这样会减少业务添加监控的代价。有如下几种方式：

1、在Nginx上对后端集群的错误率和响应时间进行监控。这样可以在整体上发现后端集群的异常。

2、在监控agent上部署插件，对服务型程序的接口进行探测，判断返回数据的格式和内容是否正常。

3、更精细的监控是开发一个公共库，所有代码在编译打包的时候都要包含该库。该公共库会自动采集程序内部的信息发给监控系统。具体对监控指标精细化到什么程度，就可以根据需求对公共库进行开发。

Q3：pc端有什么好办法防缓存和劫持吗？

A3：网站使用https防止劫持还是有一定效果的。为了更好的解决劫持，还是要通过多种方式采集用户端的数据，及时发现劫持，才能更好的给出解决劫持的对策。防止缓存需要根据需要调整好HTTP头中的缓存策略。

Q4：龚老师 您好 请问你们的监控平台是监控日志吗？？有没有使用ELK？

A4：我们的监控系统不只是监控日志，也在服务器上部署了agent采集相关的信息。在“流量接入端（Nginx）”的监控里，我们使用了ELK，实时采集Nginx的日志，分析后端集群的运行状态。

Q5: 告警收敛怎么做比较好呢？貌似不太好在精准与效率之间取得平衡

A5：告警收敛最重要的是保证告警的准确性。如果有告警一定是出了问题，而且需要人去处理。告警数量太多和没有告警几乎是一致的，因为都没法及时的追踪和处理。告警收敛也有很多方法，例如：连续多次异常才告警，过滤掉短暂的异常；告警最多发送3次，恢复正常后再报1条正常，减少告警数量；连续2条告警之间间隔5分钟，确保不会频繁的打扰在处理问题的人员；设置合理的告警阈值；设置合理的告警接收人和告警方式等。

Q6: 有什么开源的监控软件推荐吗？请问你龚老师，你们的监控系统是自己开发的还是开源的，使用到哪里技术和工具？

A6：强烈推荐Open-Falcon，尤其适合有大规模服务器的互联网公司，它的功能、性能、可扩展能力都是很强的，也非常适合做二次开发。对于服务器数量较少的公司，由于Open-Falcon的模块较多，部署起来略微复杂，可以简单的使用Zabbix。

我们的监控系统是在Open-Falcon的基础上做的二次开发，在功能上对很多前端和后端模块都进行了大量的优化。基本的架构和Open-Falcon类似，只是根据我们的需求增加了一些模块。

Q7: 监控界面，常见的告警指标可以展示下吗？

A7：当前对我们最重要的一些告警指标是：页面监控和Nginx后端集群状态的指标。这些指标出现异常，那么肯定会对用户的访问产生不利影响。其他一些指标包括：各种业务数据、流量数据、接口是否正常、端口是否存活、系统资源使用情况等。

Q8：我们目前也在建设监控平台，目前使用定时器轮询check，实现“实时”监控。有没有更好的方案，实现真正的实时监控。还有声音告警是什么样的概念？

A8：声音告警就是有告警事件的时候使用程序拨打告警接收人的电话，通话中用语音播报异常的内容。实时的监控是使用agent周期性的采集数据上报给监控服务端，在处理数据过程中使用流式计算的模型，监控后端模块每时每刻都在处理agent传输过来的数据。

Q9：如何解决告警风暴的问题？

A9：首先按照上面一个问题的回答做好告警收敛问题。另外采用合理的策略对同一个集群、同种类型的异常进行告警合并。更进一步的可以做好告警根源原因分析，直接告诉用户是什么原因导致的大量告警。例如某个交换机故障导致这个网段的服务器不可达。

Q10：针对项目后端接口的监控是无侵入式的吗？

A10：有两种：一种是无侵入式的，通过agent调用plugin对接口进行探测；另一种是类似侵入式的，需要在编译打包的时候包含一个监控相关的库文件。

Q11：怎么能尽快确认引起故障的点呢？因为故障发生时很可能有告警风暴。我这边想的是把异常日志按照时间先后汇总，有什么更好的方法吗？

A11：为了方便了解网站在全局的运行状态，用户可以在全局视图中看到各模块的运行状态和模块之间的调用状态，当某部分出现问题时能够用突出的颜色标识出来。也可以定义服务之间的依赖关系，根据各服务之间的依赖关系自动分析故障的根源原因。为了方便排查相关服务的异常，系统可以按照时间轴组织的监控异常事件展示功能，在某个服务的故障时间点附近可能有依赖服务的异常告警，从而方便用户快速定位故障的根源原因。

Q12：2.5全局系统结构视图的建立，能否展开来说下来

A12：在程序中编译打包了监控相关的库，那么监控系统就能够知道服务之间的调用关系，例如知道了A调用了B，也知道了B调用了C。那么根据这些信息就可以完整的拼出整个网站系统的调用关系网，这就是所说的全局视图。

文章来自微信公众号：高效开发运维

本文链接：https://www.yunweipai.com/13642.html