Uberのインフラストラクチャは，モバイルアプリケーションやインフラストラクチャや内部サービスをサポートする数千のマイクロサービスで構成されている。これらのサービスに高い可観測性(obervability)を提供するため，UberのObservabilityチームは２つの監視ソリューションを構築した。時系列でメトリクスベースの警告を行うuMonitorと，ホストレベルのチェックとメトリクスを扱うNerisである。どちらのシステムも，警告と重複排除のために同じパイプラインを利用している。
ObervabilityチームのシニアソフトウェアエンジニアであるShreyas Srivatsan氏によると，Uberのビジネス拡大は，同社の当初の監視および警告プラットフォームをすぐに上回ってしまった。当初彼らはNegiosを使用しており，Carbonメトリクスに対するGraphiteのしきい値チェック結果を，ソース管理下のスクリプトを使って送信していた。しかしながらNagiosでは，メトリクスチェック毎にコードを書いてデプロイする必要があったため，チームやプロダクトの成長に対してスケーラビリティが不足するようになった。同じ頃，Carbonクラスタにもスケーラビリティの問題が発生し始めていた。これをきっかけにObservabilityチームは，独自のメトリクスデータベースであるM3を開発した。
M3でメトリクスを処理するため、チームは，時系列かつメトリクスベースの警告システムであるuMonitorを開発した。本記事の時点で，uMonitorには125,000の警告が設定されており，毎秒140万の時系列にわたって7億のデータポイントをチェックしている。uMonitorの警告設定は，クエリ(GraphiteまたはM3QL)としきい値で構成されている。クエリはM3からひとつないし複数の時系列を返し，それぞれに対してしきい値が適用される。そのクエリがしきい値に違反するとアラートが起動される。
uMonitorは3つの独立したコンポーネントで構成されている。警告管理APIを備えたストレージサービスとスケジューラ，そしてワーカだ。ストレージサービスは，警告定義を格納するCassandraデータベースと，警告のためのステートマシンをラップする。スケジューラは警告を追跡し，ほぼ1分単位で警告チェックをディスパッチする。ワーカは基盤となるメトリクスに対して警告チェックを実行すると同時に，警告過多にならないようにCassandta内の状態を維持する。
エンドポイントエラーやCPU/メモリ消費量などの標準的なメトリクスは，uMonitorが自動的に生成する。その他の警告は，各チームの決定によって手動で作成することができる。現在のuMonitorは，しきい値としてstaticとanomalyの２つのタイプをサポートしている。staticなしきい値は，一貫した値を返すクエリなど，一定状態のメトリクスに使用できる。一方のanomalyは，Uberの異常検出プラットフォームであるArgosを通じてサポートされている。このシステムは，履歴データを基準としたしきい値を動的に生成する。
Uberでは，M3メトリクスシステムでは対応できないホストメトリクスを追跡するために，第2のシステムとしてNerisを運用している。Srivatsan氏によると，"各データセンタの40,000台のホストが毎分生成する，150万のホストメトリクス"を集中型データベースに格納するのは非効率的であるため，ホストに直接問い合わせる方法を選択したのだ。Nerisは各ホストにひとつのエージェントを持ち，そのホスト上で警告チェックを実行する。エージェントは起動時に，Uberの中央コンフィグレーションストアから，Object Configと呼ばれるコンフィグレーション情報を取得する。このコンフィグレーションがホストの役目となり，適切なチェックを設定する。エージェントはこれらのチェック結果を集約層に送信し，そのデータがOrigamiに送信される。Origamiは，一連のルールに従って送信すべき警告を決定すると同時に，警告の重複を排除する役割も持つ。
"カーディナリティの高さが，常に当社の警告プラットフォームの最大の課題です"，とSrivatsan氏は言う。Aaron Sun氏が書いているように，"監視システムのコンテキストにおけるカーディナリティは，システムの時系列データベースに格納されるユニークなメトリック時系列の数として定義される"。当初Uberでは，同社の高いカーディナリティに，複数の系列を返す警告クエリと，一定数の系列がしきい値を越えた場合にのみ警告を発生するというルールによって対処していた。この仕組は、明確に定義された依存関係を持ち、有限数の系列を返すクエリでは良好に動作していたが、チームが新たなプロダクトラインをサポートするために市単位やプロダクト単位、アプリのバージョン単位で警告するクエリを書き始めると、成約が成立しなくなった。
このような複雑なクエリを処理するため、ObervabilityチームはOrigamiの運用を開始した。Origamilは、前述のように重複排除と警告のロールアップが可能であるだけでなく、市やプロダクト、アプリバージョンといった組み合わせで警告を生成した上で、それらの集約ポリシで発行することができる。これらの警告定義は個々のチームのgitリポジトリに格納され、Object COnfigと同期される。
同社のプラットフォームが発展するのに伴い、警告の内容も、単にオンコールエンジニアを呼び出すものから、ロールバックやその他の軽減化行動を自動的に起動するものへと進化している。uMonitorはロールバックをフルサポートしているが、ルートをPOSTして、もっと複雑な軽減化戦略を起動することも可能だ。将来的な改善のロードマップには、より効率的なメトリック収集、警告実行インフラストラクチャの合理化、複数ソースにわたるデータの関連付けを促進するためのUIの作成、などが含まれている、