本来分享自百度开发者中心https://developer.baidu.com/article.html#/articleDetailPage?id=293491?from=01072202

导读：臣闻防患于未然者易，除患于已然者难 —— 明·马文升《添风宪以抚流民疏》作为一个程序员，是否有留意到每逢节假日在各大景区时有程序员打开电脑紧急处理线上问题？如果线上出现大量的报警，这时我们该如何判断是自身服务问题还是依赖服务问题？午夜线上重大问题出现，如何能够唤醒相关人员快速响应？相信这些问题对于很多同学都不陌生，监控的重要性不言而喻，那如何打造一个完善的监控系统，协助程序员发现并高效定位问题？本文将介绍百度游戏微服务监控实践，基于百度完善的监控基础实施，我们打造了较为完善的监控系统，下面我们向大家介绍我们的实践历程。

1. 背景

随着业务的快速发展，游戏服务端研发同学平均每人要维护 2~3 个微服务，后续业务场景增多可能会引入更多微服务，如何高效的获悉整个微服务系统的运行状态，业务异常时如何快速发现问题并解除故障，游戏服务端研发同学在监控实践上做了很多工作尝试。

初期的监控基于公司的 Argus 监控（日志服务器相关监控）、Monitor 监控平台（业务监控）、Sia 监控（可视化监控）等覆盖了一些基础的监控，但是由于缺乏体系、缺少和业务的结合，整体的效果并不理想，不少问题依然是客服和产品同学反馈，同时在跟进问题过程中研发最为头疼的一个点是在问题定位上往往要花很长的时间，这个对业务造成了一定的负面影响。在这种情况下我们系统化的梳理了面临的问题并体系化的设计和优化完善了监控系统，并着重针对问题定位做了和业务的深度结合，大大提升了问题的定位效率。

下面将就我们监控系统的建设过程整体介绍，希望对读者有所帮助。

2. 微服务监控初探

监控建设初期我们主要是基于百度的监控基础设施添加各种监控，但是由于缺乏体系效果并不理想。尽管初探阶段我们监控能力不够完善且能力较弱，但这些分散的监控措施也帮助研发同学发现了不少系统问题，为后续的体系化和多维度组合监控打下了基础。

2.1 日志和服务器监控

利用百度 Argus 监控平台，实现对机器状态和业务日志的监控，游戏微服务借助机器及日志监控能力对线上服务进行了监控的覆盖。

我们初期对 Argus 监控的应用偏单维化，结合业务场景的深度不够，诸如某个问题某些实例的监测阈值及多维度报警能力初期并没有考虑设计，下面是对于百度 Argus 监控的能力和流程介绍：

argus 整体数据流如下，可以支持电话、SMS、短信及百度如流报警

日志相关监控业界有大家熟悉的 ELK Stack 方案（Elasticseach + Logstash + Kibana），使用 Beats（可选）在每台服务器上安装后，作为日志客户端收集器，然后通过 Logstash 进行统一的日志收集、解析、过滤等处理，再将数据发送给 Elasticsearch 中进行存储分析，最后使用 Kibana 来进行数据的展示。

2.2 服务轮询监控

利用百度 monitor 监控平台，对于核心的接口采用定时轮询检测的机制来辅助监控线上服务质量，monitor 平台支持可视化配置，但是需要针对每个场景做定制化配置，随着业务快速的迭代，这种监控添加的效率和易用性已不能满足业务的需求。

2.3 服务可视化监控

利用公司 SIA 智能监控系统，实现了服务流量、可用性、性能等指标的监控可视化，可以辅助业务研发可视化的观察服务线上状态并基于线上异常状态报警。但是业务对于 SIA 智能监控能力并没有充分使用，导致可视化的辅助作用有限，智能能力没有体现。

图 3 监控可视化

对于业界的可视化监控工具，有诸如 Kibana、Grafana 等，相关的能力都已很完善，基本可以满足业务的各种展现需求，大家可以参考了解。

3. 微服务监控演进

如上面所阐述的，监控初探阶段的监控措施虽然可以辅助研发发现和定位一些问题，但是还是存在诸多问题，主要是如下四个方面：

• 风险暴露滞后，大多报警发生时已造成影响；

• 监控缺乏统一规划，相关监控项混乱且覆盖极不完整；

• 监控能力弱，无法提供有效异常信息；

• 报警混乱，研发被报警信息轰炸；

从整体监系统建设成本和收益来看，我们不会将过去的监控全部推翻，而是基于在现有基础监控的能力上加以完善。首先我们以系统化的视角对于监控系统做全面设计，然后基于设计强化监控系统各个部分的能力。

3.1 监控系统化设计

目标：有效预防、及时发现、快速止损；落地：基于系统化的设计目标，做了如下的落地思路拆解。

实现上从风险控制、智能监控、智能报警、高效定位四个方面来设计微服务系统的监控系统化工作，整体流程如下：

下面从风险控制、智能监控、智能报警和高效定位四个方面逐一介绍。

3.1.1 风险控制设计

线上问题发现的时机越早越好，由于研发同学水平客观上存在差异，且通过 cooder review 无法有效规避上线问题的发生，所以游戏业务研发在自动化 case 和发布环节做了较多的工作，以减少问题的发生。下面是研发做的主要风险控制项，通过这些风险控制项的落地，目前已经可以减少 95%以上的上线中问题。

3.1.2 智能监控设计

游戏业务初期的监控，是分散的监控添加：日志监控使用 argus，可视化的监控实验 SIA 智能监控平台，监控的覆盖和监控系统之间的协同效果并没有做全局考虑，这样就暴露出一些问题，如：

问题 1：按照监控对象划分的监控，是在单一维度上做到有效覆盖，但是系统全局波动异常如何探测？问题 2：某个实例因为网络或机器磁盘偶发故障导致 pvlost 突增，如何高效的获得信息？问题 3：系统可用性波动，是某个机房的问题，还是特定接口的问题，或是访问下游的异常？

（1）智能异常检测利用 SIA 系统的智能异常检测算法，将耗时、流量、SLA 指标、收入等指标纳入到监控体系，可以高效探测到系统的周期/非周期波动异常，下面简单介绍下主要的算法。

通过将上述指标同游戏业务的流量、耗时、收入等指标的结合，在系统周期性或非周期性的波动时，即使是较为缓慢的下降也可以通过这些周期性检测工具有效检测，大大提高异常检测覆盖度。

（2）全场景监控覆盖我们从 4 个象限覆盖监控，做到问题暴露无死角，同时针对诸如服务维度的监控，还细化了多维度的筛选能力，力求从宏观视角便于发现问题的同时也做到在微观世界能够辅助高效定位问题。

这里我们着重提下数据监控，我们针对游戏业务的特殊化场景，细化了需要监控的数据以及场景，以确保监控的完整覆盖，下面是数据相关的一些监控项。

（3）多维度监控可视化辅助多维度筛选能力：服务、接口、错误码、机房、机器实例；异常多维度可视化 ：如 pvlost 基于接口、机器、机房的分布；错误分布可视化：分接口、分错误码；

图 6 多维度监控可视化

3.1.3 智能报警设计

报警整体做了分级报警设计，基于不同的场景设置不同的报警范围和报警方式，减少了非重要报警的信息泛滥，同时在报警应用上有如下整体设计：

（1）智能合并过滤与自动升级

智能过滤：减少报警信息的过渡泛滥，做一定的信息筛选；智能报警合并：通过信息的合并，提升报警的信息简介度，进一步减少报警信息泛滥；报警自动升级：解决了困扰报警触达不了值班人的问题，通过设置不同阈值扩大到不同的范围，并升级报警的形式从邮件->如流->短信->电话，且报警电话可以设置不断的拨打直至有人响应为止，解决了触达的问题；

（2）样式内容自定义对于普通的实例报警或服务报警，相应报警信息按照固定格式进行输出；核心逻辑部分添加基于富文本的报警内容定义，完整的展示报警信息和报警问题，并提供问题的上下文语义，大大提高了信息量，为定位问题提供了充足有效的信息。

图 8 报警内容样式自定义

3.1.4 高效定位能力支持

报警暴露信息高效：对于关键核心逻辑采用 Trace 链路+机器人方式来实现报警的高效触达和自定义化输出，实现信息的高效传递；报警信息确认高效：部分注意考虑在异常信息报警后，为了确认线上的相关完整日志数据和请求当时数据情况的快速数据检索，实时 trace 系统高效的解决了这个问题；

（1）核心逻辑机器人 Trace 链路信息报警暴露信息在核心逻辑已基本达到了分钟级的问题报警 + 问题的自动定位，研发基于报警信息即可以看到对应的问题代码行数及出错原因，大大提高了问题的定位效率。

当然这个方式的报警目前还存在实现成本较高的问题，诸如在游戏业务的充值完成后给用户发道具过程中如果存在一次，我们会暴露出请求参数、出错函数及出错的具体原因，研究基于这个数据可以直观的明确具体的问题，但是这个需要较为定制化的实现，有一定接入成本。

（2）实时 trace 系统接入利用百度 trace 中台的能力，可以做到业务在非侵入式的情况下进行采集，接入成本极低。对于时效性方面采用了百度 DataHub 消息队列，并利用 Dstream 实时建索引，使得从数据源到故障定位平台可以基于关键信息的检索时效性在 5 分钟以内，大大的提高研发定位效率。

4. 微服务监控全景图

4.1 用户触达

通过多维度可视化监控，辅助研发基于可视化界面即可快速分析出问题大致原因；基于智能报警和业务报表，可以满足在时效性和业务详细健康度的全面检测，让研发同学全面感知系统的状态；

4.2 监控工具

基于公司提供的 Argus 监控、Sia 智能监控和机器人监控辅助工具，可以完整的对系统进行全面覆盖；对于一些长周期的业务数据，诸如应用日活、下载成功率、白屏率等指标数据，则提供定制化的监控以覆盖此类场景的监控；

4.3 监控指标

对于监控指标大体分位如上一些分类，基于这些分类做到监控的有效覆盖；

4.4 监控对象

监控对象从服务器、业务日志、服务状态到业务数据、业务核心逻辑和核心场景，通过全面的监控对象梳理已做到对于监控的全面掌控。

5. 总结展望

通过系统化的监控能力建设，无论是在时效性、定位效率还是覆盖度等均达到了较为理想的状态，研发对于重大的线上问题可以第一时间感知，并有完善的辅助定位信息来协助高效定位问题，总结整体监控的实践过程，主要是有以下几个方面的心得。

（1）系统化设计落地监控系统首先要明确解决的是什么问题，达到的是什么目标，将问题和目标理解清楚后，实现上就以如何充分解决问题并达成目标来思考，基于这样一个系统化的分析拆解过程，我们从风险控制、智能监控、智能报警、高效定位几个部分入手来实现我们的监控系统，以达到预期的目标。

（2）分级的思考方式在监控和报警中应用，核心逻辑集中火力无论是监控还是报警，我们都以目标集中于重要的功能和核心逻辑，如果现有工具无法达到目标，那就考虑多个工具组合来满足监控的目标。对于通用的逻辑功能则强调覆盖程度，以现有工具完整覆盖。

（3）易于实施和落地公司提供的 SIA 智能监控、argus 监控都有提供聚合的能力，对于同质的内容监控做到一步到位。而对于异构或差异化的服务，则可以以业务方现有的形式以非侵入能力支持接入，大大提高了监控的添加效率。

（4）充分结合公司现有能力，创新组合应用，提高效率在使用监控基础实施的时候，不同的监控工具各有优劣，充分利用不同的监控工具的优势达到整体监控效果的最优，同时对于诸如一些核心逻辑的监控，创新的使用机器人报警+trace 的内容定制化能力，实现对于核心逻辑问题的高效反馈和定位。

虽然在监控系统方面的实践已经达到了较为理想的效果，但是在系统故障处理、容灾等能力的自动化机制上有待进一步完善建设，且对于系统资源的使用并没有做到智能化的利用，目前资源的增减仍然有赖于人工的干预。后续的优化目标是在故障自动化处理、资源智能扩缩容上达到全面的自动化，以提供系统整体的可维护性和可用性。

————— END —————