揭秘百度微服务监控：百度游戏服务监控的演进

2021-07-15 626

导读：臣闻防患于未然者易，除患于已然者难 —— 明·马文升《添风宪以抚流民疏》

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

全文4583字，预计阅读时间 9分钟。

一、背景

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

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

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

二、微服务监控初探

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

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.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.1用户触达

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

4.2监控工具

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

4.3监控指标

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

4.4监控对象

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

五、总结展望

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

（1）系统化设计落地

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

（2）分级的思考方式在监控和报警中应用，核心逻辑集中火力

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

（3）易于实施和落地

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

（4）充分结合公司现有能力，创新组合应用，提高效率

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

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

怎样防止同事用 QQ 邮箱提交公司代码？

事情是这样的，最近组里新建了一个代码仓库来开发一个新的产品，再加上今天北京下大雨很多同事选择在家工作（包括我也是），于是我就选择用自己的个人电脑来工作。但我的个人电脑里面的 Git 信息是用的我自己的个人邮箱： git config --global user.name "Germey" git config --global user.email "cqc@cuiqingcai.com" 复制代码这两行命令大家用过 Git 的肯定都敲过对吧？这个配置是全局生效的，所以如果我用 Git 的 commit 命令来提交代码的话，那么 commit 的名字和邮箱就会变成刚才我配置的个人信息。然后如果把代码推送到公司的代码仓库里面，里面就会出现一个奇奇怪怪的用户名和头像，就像这样子：图中上面两次 commit 就是我用个人电脑提交的，最后的那次 commit 是我上周在公司用公司电脑提交的。这是不是很奇怪？如果其他人也用的个人邮箱提交，那公司代码库里面就会出现各种怪怪的提交人的记录，无从知晓。这肯定不能忍啊，以后要是有谁写了奇怪的代码都不好查是谁写的。于是乎，我灵机...

2021-07-15

492

作者 | 陈涛微服务架构的优点和痛点 1、微服务架构的诞生背景回到互联网早期时代，也就是web1.0时代，当时主要是一些门户网站，单体应用是当时的主流应用，研发团队相对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。到了新世纪互联网时代，出现了较大规模的一些应用，比如社交、电商等，流量和业务的复杂度也大幅增加，出现了几百甚至上千人的研发团队，研发团队扩大之后，协作问题成为困扰。SOA 解决方案是互联网的产物，其核心在于分布式、拆分等。但是因为 ESB 这样一些单点的组件，所以没有得到很好的推广。阿里巴巴在当时推出的 HSF、开源的Dubbo 等技术，其实是类似于分布式的一个解决方案，当时就已经有了微服务架构的理念。微服务架构正式名称的诞生是在移动互联网时代，这时的生活已经实现全面互联网化，各种各样的生活类 APP 涌现，网民以及流量复杂度相对于新世纪互联网时代显著增强。另外，较大规模的研发团队也已成为主流。这时候，大家普遍都对效率有了更高的追求，而不只是原来只有几个巨头需要有这方面的技术。微服务架构以及微服务技术的推出，如 Spring Cloud、Dubbo 等框架的...