可伸缩的微服务告警系统设计指南


Uber的软件架构由成千上万的微服务组成,有赖于此,我们的团队可以快速的自主迭代并支撑公司的全球扩张。这一架构支撑了大量的上层解决方案,如移动应用,内部基础设施服务,以及拥有复杂配置的产品,相关配置会对产品在一、二线城市的表现产生不同的影响。 

为了保障对业务扩张的支撑,以及维持架构的稳定性,Uber的可见性团队构建了一个健壮、可扩展的指标系统以及告警管道。这一系统可以监测相关服务, 以便在故障发生的第一时间延缓产生的影响并通知相关的工程师。

如图中所示,uMonitor和Neris利用一个共有的管道来发送通知并去重。稍后我们会深入了解这些系统,并探讨如何推动建立更多的缓冲措施,和我们新的告警去重平台Origami,以及在建立高“信噪比”的告警系统方面如何应对挑战。信噪比,英文名称叫做SNR或S/N(SIGNAL-NOISE RATIO),又称为讯噪比。是指一个电子设备或者电子系统中信号与噪声的比例。

此外,我们还建立了一个黑盒系统,用于侦测内部系统失败或者数据中心整体当机所引发的更高一级的系统中断。后续的文章会有讨论。

1.Uber的告警系统

图表1:在我们的告警体系中,相关服务向M3发送指标数据,uMonitor会负责检查M3中的数据并产生基于指标的告警信息。主机检测信息会发送到Neris并产生聚合和告警信息。Uber外部可以对基础设施API进行黑盒测试。

在Uber的体量下,传统的现成解决方案无法满足监控和告警的要求。我们采用开源的Nagios,结合Graphite的阈值检测,以及后端的Carbon指标系统 ,辅以源码控制脚本来解决这个问题。基于对Carbon指标系统伸缩性的考量,我们决定建立一个自有的大规模度量平台,即M3。为了提升告警系统的可用性,我们自主研发了时序告警系统uMonitor,用于处理M3中存储的指标数据。对于M3以外存储的指标数据,我们建立了Neris来进行主机一级的告警检测。

在uMonitor的开发过程中,灵活性和用例差异性是两个重要的考虑因素。有些告警信息是基于标准指标自动生成的,如端点错误或者CPU/内存占用率过高等。还有些告警信息是由某个团队根据具体的需要所建立的指标生成的。uMonitor作为一个平台系统,会对这些不同种类的用例所产生的指标进行处理,诸如:

  • 告警的易管理性:迭代产生适用于告警信息的功能和阈值。
  • 弹性措施:利用寻呼、邮件和聊天系统发送通知。支持自动化的缓解措施,如部署和配置变更的回滚等。
  • 处理海量信息:既可以响应小范围的关键事件,又不至于在大范围的中断情况下让工程团队被报警信息淹没。

2.基于指标的告警系统:uMonitor

uMonitor由三个独立组件组成:一个拥有告警管理API的存储服务,可以对Cassandra告警和状态信息进行打包存储;一个调度器,负责跟踪所有的告警信息,并时刻将报警检查任务分发到workers;一组workers用来基于告警信息自定义的指标执行检查任务。

workers会将告警检查的状态信息保存在Cassandra存储中,并通过激进的重试机制来确保相关的通知确实发送成功。只要告警信息持续产生,workers会负责进行不时的(通常是每小时1次的)重试告警。目前,uMonitor可以在1秒内使用125,000个告警配置来对140万笔时序数据的7亿个数据节点进行检查。

图表2:相关服务向M3发送指标数据,uMonitor的调度器安排相关的workers进行相关指标检查,如果检查结果超过一定阈值,就发送通知。

一条告警信息由M3查询(Graphite 或者M3QL)语句和阈值组成。阈值将决定告警是否触发。查询语句从M3返回时序数据,阈值会应用于对应的时序数据。一旦查询的结果超过了阈值,告警就会触发。借助Cassandra存储的状态信息,相关worker会维持一个状态机,以确保告警触发的状态下相关的通知成功发送,并在告警持续触发的情况下不时的重发通知,以及在事态缓解的情况下将相关通知标记为解决。

阈值一般分为两种:静态阈值和反常阈值。对于一些具备特定的、稳定状态的指标,或者我们可以构造查询来通过数值计算返回常量值的指标(如成功/失败比),通常使用静态阈值。对于一些周期性的指标,如客户在某市的行程次数或其他的业务指标,uMonitor使用Argos这个反常监测平台来生成动态的阈值,以表征基于历史数据的反常数值。

3.主机告警组件:Neris

Neris是一个基于主机的内部告警系统,用于解决M3指标系统以外的高精度的海量指标数据。将主机指标系统设置在M3之外,是基于两个原因。首先,要对每个数据中心的40,000个主机节点每分钟所产生的150万条主机指标数据进行检查,基于主机的机制相对于从中心指标存储库查询来说更加高效,严格意义上讲,相关指标的提取和存储是毫无意义的开销。其次,当前M3的保留策略是,10秒的指标数据会存储48小时,1分钟的指标数据会存储30天,对于主机指标来说,以如此的精度和保留策略存储相关数据并没无必要。开源的Nagios是以检查为单位来编码和部署的,这意味着基础设施扩张时,主机指标系统无法自动伸缩,因此我们决定自己开发一个系统来应付需要。

Neris的机制,是在数据中心的每个主机上部署一个代理,并基于单主机每分钟定时执行告警检测。随后,相关的检查结果会发送到一个聚合层,聚合层将聚合结果发送给Origami。Origami负责决定发送哪些告警信息,发送的优先级将视告警的失败次数以及潜在告警危急程度而定。基于Origami,Neris可以在每分钟对我们每一个数据中心的主机集团进行150万次检测。

主机上的代理启动时,Neris从一个名为Object Config的中心配置存储拉取主机的告警定义信息。Object Config这一机制广泛的应用于Uber的底层基础设施服务。哪些告警会被触发取决于其角色。例如,运行Cassandra的主机会运行与Cassandra状态、磁盘使用情况等指标相关的检查。绝大多数主机级别的检查由基础设施平台团队负责建立和维护。

图表3:在Neris的机制中,主机检查基于数据中心的每个主机进行,并通过Neris聚合器实现聚合,并由Origami发送告警通知。

4.处理规模数据

我们的告警平台在处理海量数据方面一直面临着巨大的挑战。传统的解决方案是,通过一条告警查询返回多条时序数据,并且只有在一定比例的数据超过阈值的时候,才使用简单的规则来触发告警通知。uMonitor同样允许用户基于告警来设置告警。如果一条告警依赖于更大范畴的告警,则一旦上一级告警触发的情况下,下级告警将被阻塞。

当查询结果返回的是既定数量的时序数据,且依赖关系可清晰定义的时候,上述方法可以工作的很好。然而,急速扩张中的Uber需要在数以百计的城市运营多条产品线,数量级的挑战需要更通用的解决方案。我们使用Origami来处理海量的任务。Neris将Origami作为主要的去重器和通知引擎,从而,uMonitor告警系统有了稳固的通知系统。

对于业务指标来说,Origami对于单城市/单产品/单应用版本的告警是用处巨大的。Origami允许用户基于城市、产品和应用版本的组合来建立潜在的告警和检查,并基于聚合策略来触发告警,来接收某个城市、产品或者应用的通知。在更大范围的系统中断的情形下(如多个城市同时发生故障),Origami会发送累积通知,用以表征已触发的告警列表。

在主机告警的场景下,Origami使我们可以基于告警的聚合状态发送不同严重程度的通知。以Cassandra集群的磁盘使用率为例,此情形下的Origami通知策略如下:

  • 当磁盘利用率超过70%的主机数小于3,则发送邮件通知。
  • 当磁盘利用率超过70%的主机数大于3,则发送寻呼通知。
  • 当磁盘利用率超过90%的主机数大于1,也发送寻呼通知。

5.告警通知

处理告警系统的伸缩问题,最主要的挑战来自于如何产生有用的告警通知。对于高优先级的事件,告警行为一般采用的通知方式是寻呼待命的工程师,而对于一般的告知类事件,是通过邮件或者聊天工具来进行通知。我们关注的重点在于构建一些缓解行为来减轻事件的影响。绝大多数的系统中断或者其他问题来源于配置变更或者部署问题。有些团队需要处理非常复杂的缓解行为运行手册,对此我们支持以webhook的方式发送POST调用,并附加告警信息完整的上下文信息,来自动化对运行手册的落地。此外,在更大范围的系统问题发生时,利用Origami的去重管道,我们可以阻塞一些细粒度的通知,以免工程团队被信息也淹没。

除了上述的手段以外,我们也致力于让通知的相关性更高,并且匹配到正确的处理者。最新的成果是,当某个服务发生变更并产生告警时,我们可以定位到配置或部署变更的所有者,并直接通知他们相关事项。并且,通过把Jaeger的追踪信息与告警信息进行结合绑定,我们可以为相关的服务失败提供更多的上下文信息。

6.告警管理

上面也讲到,之所以花大力气将uMonitor平台化,是为了让不同的团队可以基于这个平台,来处理特有的用例场景。对于不同的团队,尤其对于需要维护专有硬件的团队,以及需要为公司构建基础设施平台的团队来说,在处理诸如存储、指标管理、计算解决方案等场景的告警问题时,相关的设置和管理往往是特定的和专业化的。相关的告警设置存储在团队自有的Git库中,并向Object Config进行同步。

从更宏观的视角,uMonitor有三类告警:
– 针对所有服务来说,CPU、磁盘利用率和RPC状态这些标准的指标,会自动生成告警信息。
– 针对特定事件,经由UI产生一次性的告警信息。
– 在uMonitor之上的一层,告警信息的生成和管理通过脚本和外部配置系统完成。

当团队致力于侦测尽可能细粒度的告警事件的时候,一些初级的告警信息就会产生爆发式增长。随着Uber的全球扩张,如此细粒度的告警信息的重要性随之下降。对于支撑Uber移动应用的相关服务来说,相关的代码变更可以在几小时内,就覆盖到一部分城市的某些特定群体。在城市一级对平台的健康度进行监测,发现问题并避免问题扩散,对我们来说尤其重要。此外,工程团队和本地的运维团队所需要管理的配置参数,也因城市而异。例如,某个城市的某条街道的游行队伍,或者其他事件导致的交通情况的变化,都会影响Uber骑手的匹配。

很多的团队已经基于uMonitor构建了告警信息的发生方案,以处理类似上述的这种场景。已经解决的挑战包括:
– 迭代和生成多维告警信息
– 基于特定的业务信息(如某个国家和城市的节日)调度告警任务,并在uMonitor中存储相关的配置,以避免产生错误的告警信息
– 当静态或者反常的阈值失效的时候,可以基于历史数据,或者基于特定的业务线的潜在指标进行的复杂查询,来生成新的阈值。

此外,上述的解决方案可以生成仪表盘。相关的信息与产生的告警信息同步。

uMonitor还提供了一个强有力的编辑界面,可以展示相关的因果联系。UI的编辑和验证的功能十分重要,因为差异性以及峰值的存在,大部分的指标并不能用于告警。对于如何为告警建立更理想的查询,可见性团队会给出一些指导建议。

7.告警查询

为了允许更加定制化的解决方案,Graphite查询以及M3QL查询语言所提供的功能很多,甚至有些过犹不及。下我们举了一些示例,来展示如何让查询返回更多的常量,以使得相关指标更可用于告警:

– 使用一段时间内的移动均线指标,可以平滑掉指标中的峰值
– 在上一点的基础上,结合采用维持策略,仅当超过阈值的状况持续了一段时间之后,才发送告警通知。
– 对于一些遵循升降模型的指标,采用导数函数确保无论是上升或者下降,相关指标不会太突兀。

– 使用比率或者百分比来进行告警,以使得指标不会因绝对值的变化而受到影响。8.未来计划

如何让系统扩展的同时具备分钟级的问题侦测能力,并且仅暴露合适的信息给到用户,避免不必要的告警信息,在这方面的工作我们还只是刚刚起步。为了达成这样的目标,告警管道的方方面面都进行着大量的工作,包括:更有效的指标收集,扩展和提升告警执行基础设施的效能,构建更有效的UI和接口以处理不同来源信息的相关性等等。

关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。

本文由公众号EAWorld翻译发表,转载需注明出处。

作者:Shreyas Srivatsan

译者:白小白 

原题:Observability at Scale: Building Uber’s Alerting Ecosystem

Image placeholder
IT头条
未设置
  27人点赞

没有讨论,发表一下自己的看法吧

推荐文章
分片技术如何解决区块链系统的可伸缩性问题?

区块链技术的应用可能将改变组织存储数据和执行分布式事务的方式。即使在公共网络上,区块链也可以保证所有参与者都以安全、可靠和可验证的方式访问记录。但是区块链有一个非常明显的限制:可伸缩性。随着交易数量的

云原生时代,分布式系统设计必备知识图谱(内含22个知识点)

作者|杨泽强(竹涧)阿里云技术专家我们身处于一个充斥着分布式系统解决方案的计算机时代,无论是支付宝、微信这样顶级流量产品、还是区块链、IOT等热门概念、抑或如火如荼的容器生态技术如Kubernetes

从300万行到50万行代码,遗留系统的微服务改造

在传统企业甚至互联网企业中往往存在大量的遗留系统,这些遗留系统大多都能够正常工作,有的可能还运行着关键业务或者持有核心数据。但是,大部分遗留系统通常经常存在技术陈旧、代码复杂、难以修改等特点。笔者曾经

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

Oracle告警日志ora-04030

一oracle11g出现ORACLEORA-04030之outofprocessmemorywhentryingtoallocate报错,查询ORACLE官方MOS确定是:BUG11852492,原因

百亿流量微服务网关的设计与实现

本文从百亿流量交易系统微服务网关(APIGateway)的现状和面临的问题出发,阐述微服务架构与API网关的关系,理顺流量网关与业务网关的脉络,分享API网关知识与经验。API网关概述“计算机科学领域

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

基于JWT规范实现的认证微服务

本文由公众号EAWorld翻译发表,转载需注明出处。作者:MarceloFonseca译者:白小白 原题:Buildinganauthenticationmicro-servicewithJWTsta

微服务配置中心完全解读

本文作者:风卿,Nacos社区committer.在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力

再见微服务,从100多个问题儿童到一个超级明星

翻译| 马岛本文翻译自AlexandraNoonan的 GoodbyeMicroservices:From100sofproblemchildrento1 superstar。内容是描述 Segmen

微服务?数据库?它们之间到底是啥关系?

过去几年来,“微服务架构”这个术语持续火热,它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义,但围绕业务能力,自动化部署,网点智能以及语言和数据的分散控制

微服务治理与统计分析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:微服务架构下,服务拆得越细,服务的粒度越小,可组装性就越好;与之相对的服务之间的调用关系就会变复杂,为了保证服务更好的运行,需要对这些服务

金融行业微服务架构解析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭

美团大规模微服务通信框架及治理体系OCTO核心组件开源

微服务通信框架及治理平台OCTO作为美团基础架构设施的重要组成部分,目前已广泛应用于公司技术线,稳定承载上万应用、日均支撑千亿级的调用。业务基于OCTO提供的标准化技术方案,能够轻松实现服务注册/发现