監視もメンテナンスも不要！Prometheusオンラインサービス監視の実践ガイド

この記事は、書籍『SRE』の第 10 章「時系列データに基づく効果的なアラーム」の実践的な要約として見ることができます。

Prometheus は、Google の内部監視システムである Borgmon の (非公式の) 実装ともいえるオープンソースのビジネス監視ソフトウェアです。

この記事では、最近 Prometheus を使用して構築した、小規模から中規模 (500 ノード未満) のシステムに使用できる、完全な半自動 (手動操作が最小限) の監視システムソリューションを紹介します。

アクティブモニタリング

監視は運用・保守システムの基盤です。企業や部門の運用・保守レベルを測定するには、監視システムを見るだけで十分です。

監視方法は一般的に次の 3 つの種類に分けられます。

プロアクティブな監視：業務開始前に、運用・保守部門が定めた基準に従って監視ポイントを事前に設置します。ログ記録、ローカルエージェントへのレポート、REST APIの提供など、実装方法は様々です。
パッシブ監視：これは通常、アクティブ監視を補完するものです。サービスの機能的可用性を能動的に調査する、外部のブラックボックス監視を行います。例えば、サービスポートに定期的にpingを実行するなどです。
バイパス監視：アクティブ監視とパッシブ監視はどちらも通常、内部で行われます。内部運用が安定していても、ユーザーエクスペリエンスが正常であることを保証することはできません（例えば、ユーザーのネットワークに問題がある場合など）。そのため、世論調査やサードパーティの監視ツールなどのデータを通じて、実際のサービス品質を間接的に監視する必要があります。

アクティブモニタリングは理想的なソリューションであり、後者2つは主に補助的な用途として使用されます。この記事ではアクティブモニタリングのみに焦点を当てます。

監視は実際にはエンドツーエンドのシステム (インフラストラクチャ、サーバー、ビジネス、ユーザーエクスペリエンス) ですが、この記事ではビジネスレベルでのプロアクティブな監視にのみ焦点を当てています。

プロメテウス

なぜ他のTSDB実装（InfluxDBなど）ではなくPrometheusを選ぶべきなのでしょうか？主な理由は、Prometheusの中核機能であるクエリ言語PromQLがSQLよりもプログラム可能な計算機に似ているためです。つまり、PromQLはほぼ無制限の数のクエリ結果を生成できるということです。

例えば、HTTP サービスがあり、監視項目 `http_requests_total` を使用してリクエスト数をカウントするとします。監視データのセットは次のようになります。

 http_requests_total {インスタンス= "1.1.1.1:80" 、ジョブ= "cluster1" 、場所= "/a" } 100
 http_requests_total {インスタンス= "1.1.1.1:80" 、 ジョブ= "cluster1" 、 場所= "/b" } 110
 http_requests_total {インスタンス= "1.1.1.2:80" 、 ジョブ= "cluster2" 、 場所= "/b" } 100
 http_requests_total {インスタンス= "1.1.1.3:80" 、 ジョブ= "cluster3" 、 場所= "/c" } 110

ここには3つのタグがあり、それぞれクロール対象のインスタンス、それが属するジョブ（通常はクラスター名を使用します）、そしてアクセスパス（Nginxのロケーションと考えてください）に対応しています。Prometheusの多次元データモデルは、任意の1次元または複数の次元で計算を実行できることを意味します。

単一のマシンの QPS (1 秒あたりのクエリ数) を計算する場合は、次の式を使用します: `sum(rate(http_requests_total[1m])) by (instance)`。
各クラスター内の異なるロケーションにある各パスのQPSを計算する場合は、「sum(rate(http_requests_total[1m])) by (job, path)」を使用できます。PromQLは、ラベル「job-path」の値に基づいて結果を集計します。

PromQL に加えて、豊富なデータタイプセットにより、より有意義な監視項目を提供できます。

カウンター: インターフェイスがアクセスされる回数など、単調に増加するデータを示すために使用されます。
ゲージ: CPU 使用率、平均レイテンシなど、増加または減少する可能性のある、現在の瞬間の状態。
ヒストグラム: 95 パーセンタイルレイテンシなどの統計データの分布を表示するために使用されます。

ほとんどの監視項目はカウンターで実装できますが、一部の項目ではゲージとヒストグラムを使用します。サーバー側でのヒストグラム計算はCPUを大量に消費するため、ヒストグラムデータを大量にエクスポートする必要はありません。

最後に、PrometheusはPULLモデルを用いてリアルタイムの取得、保存、計算を行い、監視インスタンスのデータを能動的に取得します。PUSHモデルと比較して業務への介入が少なく、ログベースのオフライン統計と比較してよりリアルタイム性があります。さらに、監視インスタンスはテキスト形式の/metricsインターフェースを提供するだけで済むため、デバッグが容易になります。

サービスフレームワークの変革

私たちのチームは、統一されたサービスフレームワークを使用してプロジェクト開発を標準化し、開発の難易度を効果的に軽減します。

まず最初に、当社のサービスフレームワークをご紹介します。

Nginx のマルチプロセスアーキテクチャ (マスター/ワーカー) に似ていますが、マルチスレッドイベントループプログラミングモデルもサポートしています。
複数のアクセスプロトコル (HTTP、Thrift、PB など) をサポートしていますが、主流は HTTP です。
ビジネスロジックは、モジュール (Nginx モジュールに似ていますが、より単純です) を通じて実行するためにフレームワークにロードされます。
完全に非同期のダウンストリームアクセスAPIを提供します

サービスフレームワークが内部監視項目をエクスポートできるようにするには、いくつかの重要なタスクが必要です。

基本的なデータ型を提供する

現在、Prometheusの公式クライアントライブラリは存在せず、オープンソース実装もいくつか存在しますが、フレームワークの要件を完全に満たしていません。現在、マルチスレッドおよびマルチプロセス（初期化を除き、更新操作はロックフリー）をサポートするために、CounterとHistogramが実装されています。しかし、Gaugeはマルチプロセスシナリオにおいて監視データを集約できない場合があります（統一された集約方法がないため、すべてのデータを合計できないため）。そのため、具体的な実装は提供されていません。
基本データには、/metrics インターフェースへのデータの自動エクスポートを容易にするためのレジストリのような機能が必要です。

サービスフレームワークにポイントを含める

簡単に変化する情報をラベルを通じて表現できるだけの柔軟性が必要です。

例えば、あるWebサービスに「echo」と「date」という2つのロケーションインスタンスがあるとします。これらのインスタンスのQPS（1秒あたりのクエリ数）を追跡したい場合、「echo_requests_total」と「date_requests_total」という2つの異なるメトリクスを定義するのではなく、「http_requests_total」というメトリクスを定義し、ロケーションタグ（それぞれ「echo」と「date」）で区別する必要があります。こうすることで、インターフェースの追加や削除を行ってもコードを変更する必要がなくなります。

理想的には、ビジネスはほぼすべての通信機能の監視ポイントを自動的にインストールする必要があり、そのため、組み込みの監視ポイントは、一般的に使用される監視項目 (QPS、レイテンシ、エラー率) をカバーする必要があります。

データのキャプチャと表示

エクスポート機能が有効になると、Prometheus を使用してデータを取得できますが、まだいくつかの小さな問題が残っています。

ユーザー定義のメトリック名はPrometheusの仕様に準拠していない可能性があります。無効なデータ入力が検出された場合、Prometheusはクロールを停止します。そのため、エクスポートする前にデータをフィルタリングして書き換える必要があります。

エクスポートされるデータのサイズを制御するために、単一マシンの監視にのみ意味のある一部のデータはエクスポートから省略できます (フレームワークには単一マシンの監視ページがあります)。

Prometheus を使用する際に注意すべき点がいくつかあります。

PrometheusはCPU負荷（クエリ）とI/O負荷（データ永続化）の両方が高いため、CPUは多ければ多いほど良いとされています。また、メモリも多ければ多いほど良いとされています（クロールしたデータをキャッシュするため、不要なビジネスデータのエクスポートを最小限に抑える必要があります）。SSDの使用は不可欠です！Prometheusがメモリ使用量のしきい値に達すると、データのクロールを停止します。この停止は少なくとも数分間続き、場合によっては回復不能になることもあります。そのため、可能な限りSSDを使用してください。

Prometheusはリロードをサポートしていると主張していますが、実際にはあまりうまく機能していないようです。例えば、アラートルールファイルを変更してリロードすると、古いアラートルールと新しいアラートルールが同時に計算・実行されるようです…

Prometheus もグラフィカルインターフェースを提供しますが、非常に基本的なものです。

Grafana は通常、監視データを表示するために使用されます。

統一されたビジネスフレームワークと統一された監視メトリックにより、Grafana のダッシュボードは均一に構成することが容易です。

デフォルトのテンプレートをGrafanaにパッケージ化する方法を見つけられなかったため、新しいGrafanaプラグインを作成することで回避する必要がありました。プラグインを起動すると、各ビジネスインスタンスはこのプラグインを実行し、デフォルトのPrometheusデータソースを設定するだけで、統合監視ダッシュボードを利用できるようになります。
ダッシュボードは 3 行に分かれています。

最初の行には、リアルタイムの QPS、平均レイテンシ、平均キューイング時間、コアダンプの数、ダウンストリームエンジンの障害率、およびダウンストリームエンジンのレイテンシの変動が表示されます。
2 行目には、サービスのレイテンシ (50% および 95% のレイテンシ)、トラフィック、およびスループット (さまざまなエラーコードに応じて) が表示されます。
3 行目には、ダウンストリームエンジンのレイテンシ (50% および 95% のレイテンシ)、トラフィック、およびスループット (さまざまなエラーコードに応じて) が表示されます。

Prometheusの真価を発揮するのは、各チャートですべてのデータセンターの監視メトリクスを同時に表示でき、各メトリクスを単一のクエリで計算できる点です。例えば、1行目の5列目には、各データセンターの各下流システムの故障率が、単一のクエリでソートされて表示されています。

 topk(5, 100 *sum(rate(downstream_responses{error_code! = "0" }[5m])) by (ジョブ、サーバー)/sum(rate(downstream_responses[5m])) by (ジョブ、サーバー))

ここで、範囲ベクトルセレクターの[5m]に注意してください。これは、過去5分間のデータに基づいてレートを計算していることを意味します。この値が小さいほど、監視結果の変動が大きくなり、大きいほど、結果が滑らかになります。選択する値は、求める結果によって異なります。チャートには5m、アラームルールの計算には1mを使用することをお勧めします。業務がそれほど重要でない場合は、この値を適宜増やしてください。

この監視テンプレートは基本的に、可用性監視に対するビジネスのニーズをカバーしますが、ビジネスが独自の監視メトリックを定義して監視を実行することもできます。

アラートマネージャー

Prometheusは定期的にデータをクロールします。クロール後、アラートルールをチェックし、計算を行います。ルールが満たされると、アラートがトリガーされ、AlertManagerに送信されます。このプロセスに基づいて、監視チャートに異常が見られる場合、アラートはすでにトリガーされています。

デフォルトでは、アラームルールは10件未満に設定されています。期間の選択には注意が必要です。期間が長すぎると大きな遅延が発生し、短すぎるとわずかなトラフィックの変動でも多数のアラームが発生します。

Prometheus はアラートを生成するように設計されていますが、アラートの集約、配布、マスキングは AlertManager サービスによって処理されます。

AlertManager は現時点では非常にシンプルですが、アラートを他の受信者に配信し続けることができます。

アラートは、Webhook メカニズムを介して中間サービスに送信され、そこで別の形式に変換されてから内部アラートインターフェイスに送信されます。
PageDuty や OneAlert などのサードパーティのアラーム管理プラットフォームを使用している場合は、PageDuty の組み込みサポートまたは Webhook を使用してアラームを直接送信できます。
リソースが非常に限られているチームの場合は、アラートのアーカイブとモバイルプッシュ通知を有効にするために、電子メール + Slack を構成することをお勧めします。

より複雑なアラーム階層管理については、AlertManager はまだ長い道のりを歩む必要があり、このトピックについては将来別途議論する価値があります。

プロメテウス + グラファナ + メソス

Prometheus + Grafanaソリューションは、統合サービスフレームワークと組み合わせることで、ほとんどの中小規模チームの監視ニーズに対応できます。これらのコンポーネントをまとめてパッケージ化し、Mesosにデプロイします。統合インストールパッケージにより、監視システムのデプロイの難易度がさらに軽減されます。ユーザーはいくつかの簡単なパラメータを設定するだけで済みます。ただし、いくつか注意すべき点があります。

Prometheus と Grafana は特別な依存関係がないため、現在コンテナーにデプロイされていません。インストールパッケージは minio に保存されます。
Prometheus システムの特殊性により、通常は固定のマシンで実行し、データを固定のディレクトリに保存することで、Prometheus の再起動による影響を最小限に抑えます。
Grafanaはユーザーに提供されるインターフェースであるため、可能な限り固定されたエントリポイントを維持する必要があります。そのため、HAPROXY_CONSULを使用してGrafanaのプロキシを設定しました。

結論は

Prometheusは、強力で急速に成長している監視システム実装です。安定性、パフォーマンス、ドキュメントの面ではまだ改善の余地が残っていますが、中小規模のチームにとって最適な選択肢です。サービスフレームワークをカスタマイズし、包括的なイベントトラッキングを設計し、Prometheus/Grafanaの統合設定テンプレートを使用し、Mesosプラットフォームと組み合わせることで、リアルタイムのビジネス監視システムを半自動的に導入できます。

DUICUO