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会自动生成标准指标，如端点错误或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以便于跨多个源关联数据。
查看英文原文：