简析Uber的可伸缩监控：uMonitor和Neris

Uber 的基础设施由数千个移动应用微服务、基础设施和内部服务组成。为了获得这些服务的高可观察性，Uber 的 Observability 团队构建了两个内部监控解决方案：uMonitor（用于基于时间序列指标的警报和 Neris（用于主机级别的检查和指标）。这两个系统都使用了通用管道来修改数据和去重。

Observability 团队高级软件工程师 Shreyas Srivatsan 说，Uber 的业务规模扩展很快就超过了他们初始监控和警报平台的应对能力。最开始，他们采用了 Nagios，并使用脚本对 Carbon 指标进行阈值检查。但是，Nagios 需要为每个度量指标编写和部署代码，随着团队和产品的增长，这些种方式无法进行很好的扩展。大约在同一时间，他们的 Carbon 集群也遇到了可扩展性问题。于是，Observability 团队决定构建自己的度量数据库 M3。

为了处理 M3 中的指标，该团队构建了 uMonitor，这是一个基于时间序列指标的警报系统。在发布时，uMonitor 有 125,000 个警报配置，每秒检查 140 多万个时间序列的 7 亿个数据点。uMonitor 中的警报配置包含了一个查询（Graphite 或 M3QL）和一个阈值。查询从 M3 返回一个或多个时间序列，并将阈值应用于每个时间序列上。如果查询违反了阈值，就会触发警报。

uMonitor 由三个独立的组件组成：提供了警报管理 API 的存储服务、调度程序和工作程序。存储服务对 Cassandra 数据库进行了包装，用于存储警报定义和警报的状态机。调度程序负责跟踪警报，并以分钟为间隔调度警报检查。工作程序针对底层指标执行警报检查，同时将状态保存到 Cassandra 中，以确保它们不会过度警报。

uMonitor 架构

uMonitor 会自动生成标准指标，如端点错误或 CPU/内存消耗。其他警报可以由每个团队手动创建。目前，uMonitor 支持两种类型的警报阈值：静态和异常。静态阈值对于稳定状态度量标准非常有用，例如总是返回一致值的查询。异常阈值由 Uber 的异常检测平台 Argos 提供支持。这个系统基于历史数据生成动态阈值。

Uber 维护着第二个系统 Neris，用于跟踪不存在 M3 指标系统中的主机指标。Srivatsan 说，他们发现在一个集中式数据库中存储“数据中心 40,000 台主机每分钟产生的 150 万个主机指标”非常低效，所以他们选择直接查询主机。Neris 在每台主机上运行一个代理，对该主机执行警报检查。在启动时，代理从 Uber 的中央配置存储（称为 Object Config）中获取配置。配置将决定主机的角色，主机负责设置适当的检查。代理将这些检查的结果发送到聚合层，然后聚合层将数据发送到 Origami。Origami 负责根据一系列规则来决定应该发送哪些警报，并对警报进行去重。

Srivatsan 表示，“基数太高一直是我们警报平台面临的最大挑战”。正如 Aaron Sun 所写的，“监控系统环境中的基数是指存储在时序数据库中唯一的指标时序的数量”。最初，Uber 通过让警报查询返回多个时序并且只有在足够的时序超过阈值时才触发警报来解决高基数问题。这种情况适用于返回有限数量的时序查询。但是，当团队需要针对每个城市、每个产品和每个应用程序版本查询警报时，就不再适合使用这种方式了。

该团队开始使用 Origami 来解决这些更复杂的问题。如上所述，Origami 能够进行数据去重和警报汇总。它还能够针对城市、产品和应用程序版本的组合创建警报，然后基于汇总策略触发警报。这些警报定义存储在各个团队的 git 存储库中，然后同步到 Object Config。

随着平台的发展，警报已经从简单地通知轮班待命的工程师演变成可以自动触发回滚和其他缓解活动。uMonitor 为回滚提供了完全支持，也可以 POST 到路由以触发更复杂的缓解策略。进一步的路线图改进包括更有效的度量收集、简化警报执行基础设施，以及创建 UI 以便于跨多个源关联数据。

查看英文原文：

https://www.infoq.com/news/2018/12/observability-uber