运维监控AIOps的几个重要观点

Posted 2023-04-09 夜莺云原生监控

监控是整个运维乃至整个产品生命周期中最重要的一环，通过配置合理的告警机制，采集准确的监控指标，来提前或者尽早发现问题，解决问题，进而保证产品的稳定，提升用户的体验。『分布式实验室』特约记者艾尔斯兰（下文称艾尔）采访了Nightingale核心开发者秦晓辉，就什么推动监控系统更新，可观测性三大模块怎么关联，以及Nightingale的定位做了交流。

Nightingale是一款先进的开源云原生监控分析系统，采用All-In-One的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。

艾尔：过去10多年以来，比如Zabbix、Open-Falcon、Prometheus、Nightingale等主流使用的监控系统一步一步变化和发展，作为监控领域资深开发者，你认为行业内的哪些变化在推动着监控系统或着运维支撑平台的迭代和更新？

秦晓辉：行业内最大的变化，有这么几点：

指标数量大幅增长：微服务的流行，要监控的服务数量大幅增长，是之前指标数量十倍都不止，而广大研发工程师，也越来越重视应用可观测性的能力建设，更愿意在服务中埋点

指标生命周期变短：云原生的流行，让容器创建、销毁变得非常频繁，原来的物理机、虚拟机时代，监控系统更多的是资产管理视角来看待监控对象，云原生之后，资产视角已经不合适

指标维度更为丰富：老一代监控系统更多的是关注机器、交换机、中间件的监控，每个监控对象用一个唯一标识来区分，没有指标维度的设计，而现在，按照不同维度的聚合已经成为基本需求，每个指标动辄几个、十几个标签

所以，对时序库的要求一下子拔高了很多，产品体验上，也逐渐从资产管理式的监控过渡到了关注应用和业务，引入了灵活的查询聚合语法，确实是一个长足进步。

艾尔：当系统出现问题的时候为了快速定位，我们往往需要不同维度的监控数据按照时间轴垂直关联，Nightingale后续版本有没有相关功能考虑？

秦晓辉：按照时间轴垂直关联，现在的Nightingale版本已经支持了，我们提供两种视图：一个是监控大盘，一个是快捷视图，可以选择某个时间段，查看这个时间段内多个指标，便于排查定位问题。另外，我们还在活跃告警方面，提供了聚合视图，不但可以基于时间轴聚合，也支持自定义聚合标签，比如查看最近1小时内所有云平台的、Ceph产品线的活跃告警事件，算是Nightingale的一个小创新。

艾尔：系统可观测行方面，监控指标/日志/链路跟踪是三大不同模块，为了达到更好了解系统现状和定位问题，我们往往需要这三模块数据相互关联，您在过去工作当中怎么解决相关问题？以及Nightingale有没有考虑相关工作？

秦晓辉：这个问题非常好，可观测性三大支柱，指标/日志/链路追踪，如何做关联，整体来看，典型的手段有三个，一个是时间维度的关联，一个是标签维度的关联，最后一个是数据层面的关联。

时间维度的关联，大家比较容易理解，每一条指标、日志、链路信息，上报的时候都带上时间戳，那我们就可以查看某一时刻相关的数据了。

标签维度的关联，是重点，即为不同的数据附上相同的标签，通常需要在采集器上做。比如我司（快猫星云，我们近期创业的公司 ）近期开源了一款采集器：Categraf，其目标就是all-in-one，既可以采集指标、日志，也可以接收链路追踪数据，数据都是从一个采集器上流经。

故而，采集器就可以自动附上一些通用指标，最典型的就是所在机器的标识，作为标签附到监控数据上，当然，用户也可以自定义标签，比如监控Tomcat、Categraf既可以采集Tomcat的指标，也可以采集Tomcat的日志，我们可以为这两类Tomcat数据都附上source=tomcat，service=svr-xx，region=idc-yy的标签，未来就可以通过这些标签做到关联查询。

至于数据层面的关联，典型的是TraceID，链路追踪数据都会有一个TraceID，日志中也可以打印TraceID，这样未来查询的时候，就可以用一条TraceID关联查询到相关的所有span和日志。

艾尔：运维人员负责系统日常运维和维护，但是运维人员工作量和成果怎么量化一直是个难点，从运维支撑平台的角度出发，在系统层面上有哪些更有效量化运维人员产出的设计和方法？

秦晓辉：运维人员也有多个不同的工作方向，这里拿两个方向举例，一个是稳定性建设，一个是日常事务性支撑。

首先说稳定性建设，从平台角度来看，既可以管理稳定性目标，也可以量化稳定性建设过程，比如我们可以建立SLO度量平台，来度量各个产品的SLO达成情况，定义SLO相关的SLI，并在平台上自动计算SLI和SLO数据，这些数据优秀，就表示相关人员的稳定性建设有成效。

对于稳定性建设过程，我们也可以建立平台来度量和辅助。比如监控规则配置的是否完备、告警事件是否过多、上线过程是否严格遵从军规、预案是否定期做了演练、预案是否在每次故障中都发挥了作用（即预案有效率）等等。

之前在前司我们做的类似平台称为健康分度量系统，有监控健康分、预案健康分、变更健康分等，各产品线有榜单，以此督促推进各产品线改造。分数的高低，一定程度上是可以说明相关人员的工作量和有效程度的。

另一个是日常事务性支撑工作，可以建设工作台工单类的系统，张三今年总共处理了多少工单，每个工单的50分位处理时长是多少，需求方的满意度评价分数是多少，重复类工作的时长是否在逐渐变短（比如通过建立工具来缩减），自动化工单的占比是否在逐步提高等等，均可以在这么一个平台上量化。

艾尔：告警灵敏度和噪音一直是比较严重的问题，告警噪音不但增加无效的运维工作同时也会干扰有效运维工作的顺利进行，在真实工作环境中怎么找到一个运维工作压力和系统可靠性之间的平衡点？

秦晓辉：这里有几个手段可以多管齐下。

一是告警分级管理，定义北极星指标（这是最重要的手段之一，我们甚至专门做了一个管理北极星指标的产品），所谓的北极星指标，是反映业务健康度的最重要指标，通常和营收挂钩，和终端用户的关键体验挂钩。

比如交易类的系统，订单量就是一个典型的北极星指标，这类指标是公司管理层最关注的指标，可以看做是实时BI数据，需要高优保障。而某个机器的CPU飙高了，可能也是个告警事件，但是未必会对北极星指标造成影响，特别是现在微服务多实例部署，某个实例有问题，通常不会对整体服务有影响，这类的告警就是低优告警，可以无需太过紧张，放到工作队列中逐步处理即可。

其次要有最佳实践和量化手段，最佳实践是有方法论可以参考的，比如Google提出的四个黄金指标，USE和RED原则，可以指导我们重点关注什么样的指标，给什么样的指标配置告警。而量化手段，上一个问题的回复中已有提及，我们得知道哪些告警发的最多，哪些人收的最多，哪些告警规则里没有关联预案链接，逐步的去治理，当然，最好能写入相关人员的KPI，推动起来会更为容易。

艾尔：Nightingale的定位可不可以理解为prometheus-stack的统一WebUI，解决Prometheus/Alertmanager/Grafana比较割裂并易用性较低的问题。可能是因为从性能和功能角度考虑，目前个人感觉Nightingale整体架构比较复杂，后续有没有针对中小企业小规模测试环境或针对个人开发者的简化版本，保留UI易用功能的同时架构上简化降低部署和后续运维成本相关的计划？

秦晓辉：Nightingale的定位，姑且可以看做是Prometheus的企业级版本，假设有个团队，自己搭建了一套Prometheus，给自己团队的几个人来用，用Prometheus+Grafana+AlertManager，其实是够用的（当然，这里暂不考虑团队里的这几个人的学习成本）。

那如果这个团队想要建立更大的影响力，想要把这套监控能力推广到全公司，就需要有一套有权限管理的UI，毕竟不能让每个人都来修改yaml文件。而Nightingale不但提供了这个Ul，还有很多附加能力，比如更多告警规则的特性、告警自愈贯通、告警事件的聚合查看视图、历史存档、新增一些除了大盘之外的快速查看视角等等。

另外，我们近期也推出了采集器Categraf，和Nightingale无缝集成，在采集器上落地最佳实践和经验沉淀，在Nightingale里内置告警规则、监控大盘等，省去大家去网络上各种查找的精力，欢迎大家一起来共建，功在当代，利在千秋。

对于架构复杂度的问题，可能是受到了我们官方文档的架构图的影响，哈哈。实际上，那个架构图是画的最复杂的情况，如果只是小规模使用，可以部署单机版本，只需要部署n9e-server和n9e-webapi两个模块，以及依赖的相关开源组件即可。我们提供了docker-compose方式帮助大家一键部署，也提供了依赖的开源组件的一键部署脚本，欢迎大家尝试。当然，我们也会持续优化，争取在未来继续降低部署复杂度，让个人开发者也能轻松尝试。

艾尔：AIOps作为多年前提出来的新概念，但是业界一直没有比较成功的实际生产场景中落地的案例，您觉得主要问题出现在什么地方？您如何看AIOps的未来发展前景？

秦晓辉：这也是一个好问题，我说一下个人理解，AIOps是很有前景的，但是有两个前提，一个是建立完备、规范的数据，二是找到合适的场景。有些人说要用AIOps干掉现在的运维人员，这无疑是天方夜谭。

我们现在创立的公司，做了很多帮助用户建立完备的监控数据体系的事情，坦白讲，在当下的国内环境，绝大部分公司，都没有很完备的监控数据，比如上面提到的北极星实时BI指标，大部分公司就没有，而如果没有完备的数据，又何谈AI？其次是数据没有规范，没有贯通，即：从源头上来看，没有良好的用于训练算法的物料，所以也就不会有很好的AI的效果。

第二点是场景，目前来看，AIOps在智能告警这个场景，是相对成熟有效的，如果大家想要尝试AIOps，建议从这点开始切入。刚才我们讲到数据的建立其实现在各个公司做的并不好，为什么却说智能告警又相对成熟有效，这是因为，智能告警依赖的数据是相对完备的。

很多用统计学算法来告警的做法，都是针对单个series（监控时间线，就是监控大盘上的一条折线图表示的监控数据），没有额外的依赖，所以这个路子是可以走通的，前几天我们做了一场直播，讲解了如何在Nightingale中开启智能告警的能力，就是因为我们自己实践觉得效果还是不错的。

嘉宾介绍：

秦晓辉，山东人，毕业于山东大学，Open-Falcon、Nightingale、Categraf核心研发，快猫星云联合创始人。

特约记者：

艾尔斯兰，17年北京大学计算机科学技术专业毕业，目前任职商汤科技资深开发工程师，毕业后一直在从事云原生相关工作。

AIOps 对监控报警架构的挑战

作者简介
周伟 百度高级研发工程师

负责百度智能运维（Noah）监控报警系统、通告平台；在精准报警、精准通告、报警收敛、公/私有云监控等方向具有广泛的实践经验。

监控报警是故障发现的重要一环，也是百度在AIOps的最早切入方向之一，目前百度 AIOps 在监控报警方面已经有两个场景取得突出效果：智能异常检测和智能报警合并。

如何支撑 AIOps 算法在监控报警系统的快速落地并产生业务价值，这对监控报警架构提出了很大的挑战！本文首先介绍百度Noah监控报警的功能和业务模型，然后重点分析百度监控报警系统在落地 AIOps 过程中遇到的挑战。

百度Noah监控报警系统

首先我们介绍下百度的标准故障处理流程，如上图所示，主要分为以下7个过程：

1. 故障发生：比如当内网机房核心交换机发生故障时，会造成内网的网络故障，从而导致产品线的流量损失。

2. 故障发现：监控系统实时检测到产品线的流量异常。

4. 故障止损：业务运维人员会执行故障预案，或者借助故障自愈平台智能地执行故障止损操作，以达到快速止损的目的，常见的操作是将流量从故障机房切到非故障机房。

5. 故障定位：运维人员和研发人员一起定位故障根因。

6. 故障恢复：当定位到问题后，运维人员开始执行修复操作，直到线上的所有服务（包括未接流量的模块）都彻底恢复正常。

7. 故障总结：运维人员会对故障处理流程进行复盘总结，好的方面继续保持，不好的方面排期改正。

在整个故障处理流程中，监控系统主要负责故障发现到故障定位的环节；报警系统作为监控系统的子系统，主要负责故障发现和故障通告。

百度Noah报警系统最早服务于百度内部的监控平台，提供从机器、实例到上层业务等全方位、立体化的监控报警能力，已经覆盖百度的所有产品线。同时，系统面临很大的挑战，每秒需要处理千万级个数据点，线上的监控配置已经达到百万级别，每天会产生千万个报警事件，在这么大的量级下，还需保证秒级的报警时效性。

百度Noah报警系统不仅为百度内部用户服务，我们还同时为公有云和私有云服务提供监控报警能力。我们将内部强大的监控产品和运维理念输出到业界，打造了NoahEE产品（详见《》介绍 ），帮助客户一起提升运维效率和线上稳定性。另外，我们还依托报警系统孵化出了百度AIOps智能运维产品，包括智能异常检测、故障定位、报警合并等高级功能，已经落地金融、交通、互联网等行业，受到客户一致好评。

业务模型

监控报警系统的核心使命是精准报警，那报警系统是如何进行故障发现和故障通告呢？我们通过一个场景来了解下。

假设上图中的曲线是某产品线的流量指标（简称PV），其中每个点代表一个PV数据点，假设希望当PV值小于100时，异常判断结果为异常，并通告给业务运维人员。

相应地，我们将监控报警系统拆分成以下三个子系统：

• 异常判断系统：主要功能是根据异常判断配置周期性地对数据进行判断，并将产生的判断结果（正常或异常）发送给下游。异常判断系统不仅需要提供基于传统四则运算的异常判断，还需要提供基于AIOps算法的异常判断。

• 事件管理系统：主要负责报警事件的管理工作，并基于报警事件提供防抖动过滤、报警认领、逐级通告、报警静默等功能。

• 通告发送系统：主要负责报警合并、渲染和发送等功能。另外为了防止下游发送网关的带宽被某些业务的突发报警流量淹没而导致其它业务的报警消息得不到及时发送，还需要提供配额和流控功能，从而保证每个业务公平地使用发送网关资源。

将监控报警系统拆分成三个子系统后，有以下两个好处：

• 系统功能边界清晰，具备可扩展的报警架构能力

每个子系统可以根据自身的功能特点采用不同的技术栈和部署架构，由不同的研发工程师负责研发和维护。比如异常判断系统更偏向计算逻辑，可以采用Golang或C++这类更加注重执行效率的技术栈；而事件管理和报警发送系统更偏向于业务逻辑，可以采用Java或PHP等更注重研发效率的技术栈。

每个子系统也可以独立进行功能和架构升级。比如异常判断系统需要大量的CPU资源，比较适合采用集群架构，这样方便横向扩展，增加系统吞吐能力；而通告发送系统的流量相对小些，初期可以采用主备架构，不仅架构简单可靠，而且研发和维护成本小。假设随着业务的发展，业务需要更大的报警发送能力，通告发送系统只需保证对外接口不变，独立将自身架构升级为集群架构，就可获取更大的报警发送能力。

• 报警功能组件化，具备灵活的商业化交付能力

每个子系统都是一个独立的功能组件，可以独立部署、升级，这样就具备灵活支持商业化交付能力。比如我们可以只将通告发送系统单独交付给商业化客户，客户通过直接调用通告发送的接口就可以获取报警合并、渲染、发送等能力。

我们遇到了哪些挑战？

通过上面的业务模型介绍，大家已经对监控报警系统有了全局的认识，那下面来详细分析落地AIOps遇到的问题。

1 落地AIOps算法周期长，迭代成本高

我们继续来看PV指标，通过对历史PV数据的观察，我们发现不同时间段的PV大小是上下波动的，比如在早上八九点是流量高峰期，在凌晨两三点是流量低峰期，另外工作日和周末的流量大小也是不同的。这意味着，我们不可能设置统一的阈值来检测PV流量的变化情况，那么怎么办呢？

百度策略人员研发了基于鲁棒回归的无监督突升突降检测算法，这个算法不需要设置PV阈值，即可检测流量的变化。下面展示的这个公式是其中的一步，其中变量y就是真实的PV值，f(x)代表利用某种算法预测到的PV值。如果对算法细节感兴趣，可参考文章：《我们不一样！告诉你百度是如何做智能流量异常检测的》。

这类异常检测算法相对于传统的四则运算，有以下不同：

• 对不同类型指标在不同的场景下，算法f(x)是不相同的，特别是在初期探索阶段，我们需要快速迭代算法，以验证哪种算法效果最优。

• 算法f(x)会依赖根据历史数据训练到的模型，然而业务数据的特征复杂，不断变化，这意味着我们需要定期更新策略模型，以保证算法的效果。

• 算法f(x)对CPU资源的需求差异很大，有的算法计算量非常小，可能单个CPU核就可以运行数千个此类任务，而有的算法会引入RNN等深度学习算法，计算复杂度特别高，往往就需要独占某个CPU核。

最初我们落地这类AIOps算法时，整体的流程如上图所示：

1. 策略工程师用Python或Matlab编写算法脚本，并在线下进行Case回溯，保证算法的普适性。

2. 研发工程师将算法脚本改写成线上代码（C++或Java），以便在线上运行。

3. 测试工程师对改写后的算法代码进行测试回归。

4. 运维工程师对模块（包括算法代码和策略模型）进行发布上线。

上面的研发流程暴露出很多的问题。一方面，对我们的研发工程师要求比较苛刻，既需要看得懂策略算法，又要熟知工程研发；另一方面，算法的迭代周期比较长，经常以月为单位，可能算法刚上线，数据特征就发生了变化，导致算法失效；最后，即使算法程序迭代稳定了，但是参数模型还需要定期更新，由于参数模型和算法程序没有分离，导致后期参数模型的更新需要不断上线，提高了维护成本。

2 报警管理需求繁杂多样，疲于应付

我们再来看下报警管理的挑战。报警管理需要处理的需求比较多，我们以一个典型的运维场景来串一下这些需求：

• 凌晨一点，网络运维工程师对网络进行调整，导致网络产生了短时间的抖动，这类抖动的持续时间通常都在1到2分钟左右。网络抖动导致大量的业务监控指标发生相应的抖动，从而触发报警。此时业务运维工程师就希望系统能够提供防抖动过滤功能，避免指标在短时间抖动时触发报警。

• 但是，当值班工程师被及时唤醒并开始处理故障后，系统持续的重复提醒会对值班工程师形成很大的干扰。因此工程师们就希望引入报警认领功能，告知报警系统故障已经有人在处理，重复提醒可以停止了。

• 凌晨4点半，由于值班工程师是新入职的，对系统不够熟悉，日志清理的操作还未完成，导致故障持续。此时，就希望系统能够提供报警升级功能，在故障长时间未解除的时候可以通知资深的二线值班工程师介入处理。

• 凌晨4点50，二线值班工程师完成日志清理，故障恢复。

  这时，二线工程师发现日志清理操作其实是一套标准的止损操作，完全可以在发生报警时自动执行。因此希望系统能够提供报警回调功能，将来类似的问题就无需人工介入处理了。

• 除此之外，值班工程师可能还有断流检测、报警静默等等各种需求。

可见报警管理的需求复杂多样，如果我们不能抽象出一个可扩展的报警管理模型，我们将变得越来越被动。

3 报警风暴淹没核心报警，束手无策

看完报警管理，我们再来看下报警风暴的挑战。

为了避免遗漏故障，运维工程师常常会在监控系统中定制大量的监控指标和报警规则，从而建立起从网络到机器、从实例到模块、再到上层业务的立体化监控。立体化的监控虽然极大提高了故障发现的能力，但是很容易导致一个故障触发大量报警，造成报警风暴。

为了让大家认识报警风暴的真面目，我们来看三个典型的场景：

1. 机器故障：机器发生故障时，监控机器健康度的报警规则将会产生报警；然后监控机器上实例运行状态的报警规则也会产生报警；最后这些实例的上游应用模块也会受到影响，相关的报警规则也会开始报警。这样一来，一个机器的故障就可能会产生几十条的报警消息。

2. 应用模块故障：首先这个应用模块中的所有实例都会发出报警，紧接着上游应用模块也会产生报警。当应用模块中包含的实例比较多时，这类故障常常会产生数百条的报警消息。

3. 机房故障：会同时造成网络、机器、域名、应用模块、业务等多层次、多方面的异常报警，产生的报警消息可以多达数万条。

   
   

总结

本文首先介绍了百度Noah监控报警系统功能和业务模型，然后结合案例场景分析了我们在落地AIOps时遇到的问题，让大家对监控报警系统的现状有一个直观的认识。我们将在下篇文章中讲解如何来解决这些挑战，敬请期待。

GOPS 2020 · 深圳站有哪些精彩专场？

新出炉的专场图了解一下

点击阅读原文，访问大会官网

你点的每个在看，我都认真当成了