How to select the monitoring system

多様なモニタリングシステム

モニタリングは常に IT システムの中核を担う要素であり、問題の発見と原因究明を担ってきました。従来の運用保守、SRE、DevOps、開発者を問わず、すべての IT 担当者がモニタリングシステムに関心を持ち、その構築と最適化に携わる必要があります。メインフレームのオペレーティングシステムや Linux の基本指標の時代から、モニタリングシステムは登場し、徐々に進化してきました。現在、検索できるモニタリングシステムは 100 種類以上に上り、さまざまな基準で分類されています。例を挙げます。

1. 監視対象による分類：汎用型（汎用的なモニタリングモードで、ほとんどの監視対象に適用可能）、特殊型（特定の機能に特化。Java JMX システム、CPU の高温保護、ハードディスクの電源障害保護、UPS 切り替えシステム、スイッチ監視システム、専用線監視など）

2. データ取得方式：プッシュ型（CollectD、Zabbix、InfluxDB）、プル型（Prometheus、SNMP、JMX）

3. デプロイモード：結合型（監視対象と同一ホストにデプロイ）、スタンドアロン型（独立したシングルインスタンスとしてデプロイ）、分散型（水平スケーリングが可能）、SaaS 型（多くの商用ベンダーがデプロイ不要の SaaS を提供）

4. データ取得インターフェイス：インターフェイスタイプ（特定 API 経由でのみ取得可能）、DSL（PromQL や GraphQL など、一定の計算機能を備える）、SQL（標準 SQL、SQL ライクなクエリ言語）

5. 商用属性：オープンソース無償型（Prometheus、InfluxDB スタンドアロン版など）、オープンソース商用型（InfluxDB クラスター版、Elastic Search X-Pack など）、クローズドソース商用型（DataDog、Splink、AWS Cloud Watch など）

Pull か Push か

企業内部で使用するモニタリングシステムプラットフォームを構築する場合、オープンソースソリューションを独自に採用するか、商用 SaaS 製品を利用するか、選択肢は数多くあります。しかし、どちらの方式を選んでも、実際に運用を始める前に、データをどのようにモニタリングプラットフォームに渡すか、あるいはプラットフォーム側からデータをどう取得するかを検討する必要があります。ここでデータ取得方式の選択、つまり Pull モデルと Push モデルのどちらを採用するかという問題が生じます。

Pull ベースのモニタリングシステムは、名前の通り、モニタリングシステム側が能動的にメトリックを取得する方式で、監視対象はリモートからのアクセスを可能にしておく必要があります。一方、Push ベースのモニタリングシステムは能動的にデータを取得するのではなく、監視対象側からメトリックを能動的に送信します。この 2 つの方式は多くの点で異なります。モニタリングシステムの構築と選択にあたっては、事前に両方式のメリットとデメリットを理解し、適切な方式を選択して導入する必要があります。そうでなければ、安易な導入はモニタリングシステムの安定性やデプロイ・運用保守コストに深刻な影響を及ぼす可能性があります。

Pull vs Push の概要

以下ではいくつかの観点から比較を行います。読者の時間を節約するため、まずは概要を表で簡潔にまとめます。

原理とアーキテクチャの比較

上図に示す通り、Pull モデルのデータ取得の中核は Pull モジュールで、一般的に Prometheus のようにモニタリングバックエンドと同じ場所にデプロイされます。主要コンポーネントは以下の通りです。

1. サービス検出システム：ホストのサービス検出（一般的に企業の CMDB システムに依存）、アプリケーションのサービス検出（Consul など）、PaaS のサービス検出（Kubernetes など）を含み、Pull モジュールはこれらのサービス検出システムと連携できる必要があります。

2. Pull コアモジュール：サービス検出部分に加え、一般的に共通プロトコルを使用してリモートからデータを取得します。Pull 間隔、タイムアウト間隔、メトリックのフィルタリング、名前変更、簡易処理機能の設定をサポートします。

3. アプリケーション側の SDK：固定ポートをリッスンし、Pull される機能を提供します。

4. 各種ミドルウェアや外部システムは Pull プロトコルに準拠していないため、対応する Exporter エージェントを開発して、それらのシステムのメトリックを取得し、標準 Pull インターフェイスを提供する必要があります。

Push モデルは比較的シンプルです。

1. Push エージェント：各種監視対象のメトリックデータを取得してサーバーに送信します。監視対象と同じ場所にデプロイすることも、個別にデプロイすることも可能です。

2. 構成センター（オプション）：集中管理型の動的設定機能を提供します。監視対象、取得間隔、メトリックのフィルタリング、メトリック処理、リモート送信先などを設定します。

3. アプリケーション側の SDK：モニタリングバックエンドまたはローカルエージェントにデータを送信する機能を提供します（通常、ローカルエージェントはバックエンド互換のインターフェイスも実装しています）。

まとめ：デプロイの複雑さの面では、ミドルウェアや外部システムの監視において、Pull モデルのデプロイ方式は複雑すぎ、運用保守コストが高いのに対し、Push モデルの方が便利です。アプリケーション側でメトリックポートを公開するコストと能動的にプッシュするデプロイコストは、どちらの方式でも大差ありません。

Pull の分散ソリューション

スケーラビリティの面では、Push モードのデータ収集は本質的に分散型であり、モニタリングバックエンドの処理能力が追いつく限り、無制限に水平拡張できます。対照的に、Pull モードの拡張はより煩雑で、以下が必要です。

1. Pull モジュールをモニタリングバックエンドから切り離し、Pull をエージェントとして別途デプロイする。

2. Pull エージェント間で分散協調を行う必要がある。一般的に最もシンプルな方法はシャーディングである。たとえば、サービス検出システムから監視対象マシンのリストを取得し、それらのマシンをハッシュ化してからシャーディングを行い、どのエージェントがどの Pull を担当するかを決定する。

3. 各 Pull エージェントを管理するための新しい構成センターを追加する（オプション）。

お気づきの方も多いでしょうが、この分散方式にはまだいくつかの問題が残っています。

1. シングルポイントのボトルネックが依然として存在する。すべてのエージェントがサービス検出モジュールにリクエストを送る必要がある。

2. エージェントを拡張すると監視対象が変動し、データの重複や欠落が発生しやすい。

モニタリング機能の比較

監視対象の生存確認

生存確認はモニタリングにおける最初の、かつ最も基本的な作業です。Pull モードでは、監視対象の生存確認は比較的簡単です。Pull モジュールの中心からターゲットのメトリックを直接リクエストすればよく、失敗した場合はネットワークタイムアウトや接続拒否などの基本的なエラー情報も取得できます。

Push モードでは生存確認がより煩雑です。アプリケーションからのレポートが失敗した原因として、アプリケーション自体が停止した可能性、ネットワークの問題、他のノードへの移行などが考えられます。Pull モジュールはサービス検出とリアルタイムに連携できますが、Push はそれができないため、サーバー側でサービス検出と再度連携して初めて、失敗の具体的な原因を把握できます。

データの完全性計算

データの完全性の概念は、大規模モニタリングシステムにおいて非常に重要です。たとえば、1,000 台のアプリケーションの QPS を監視する場合、1,000 台分のデータを集約する必要があります。データの完全性を考慮しないと、QPS が 2% 低下したらアラームを発するように設定した場合、ネットワーク変動で 20 台以上のデータが数秒遅れただけで誤アラームが発生してしまいます。そのため、アラームを設定する際は、データの完全性も総合的に考慮する必要があります。

データの完全性計算もサービス検出モジュールに依存します。Pull 方式ではデータをラウンドごとに取得するため、1 ラウンドの Pull が完了した時点でデータが完備されます。一部の取得が失敗しても、不完全なデータの割合を把握できます。

Push モードでは、各エージェントやアプリケーションが自律的にデータを送信します。各クライアントの Push 間隔やネットワーク遅延が異なるため、サーバー側で履歴データに基づいてデータの完全性を計算する必要があり、コストが高くなります。

短生命周期/サーバーレスアプリケーションの監視

実際のシナリオでは、短生命周期やサーバーレスのアプリケーションが数多く使用されています。特にコスト効率を重視する場合、ジョブ、フレキシブルインスタンス、非サービス型アプリケーションなどを多用します。たとえば、レンダリングタスクが発生したらフレキシブルコンピューティングインスタンスを起動し、完了後ただちに破棄してリリースします。機械学習のトレーニングジョブ、イベント駆動型の非サービス型ワークフロー、定期実行されるジョブ（リソースクリーニング、容量チェック、セキュリティスキャンなど）も同様です。これらのアプリケーションのライフサイクルは非常に短く（秒やミリ秒単位の場合もある）、Pull の定期取得モデルでは監視が極めて困難です。一般的に、Push を使用してアプリケーションからモニタリングデータを能動的に送信する必要があります。

こうした短生命周期アプリケーションに対応するため、純粋な Pull システムでは中間レイヤー（Prometheus Push Gateway など）を用意します。アプリケーションからの能動的な Push を受け取り、モニタリングシステムに対して Pull ポートを提供します。しかし、これにより中間レイヤーの管理と運用保守コストが発生します。さらに、Push を Pull でシミュレートするためレポート遅延が増加し、すぐに消えるメトリックのクリーンアップも必要になります。

柔軟性と結合度

柔軟性の面では、Pull モデルに一定の利点があります。Pull モジュールで必要なメトリックを設定し、メトリックに対して簡易計算や二次処理を行えます。ただしこの利点は相対的なもので、Push SDK やエージェントでも同様のパラメータ設定が可能です。構成センターを活用すれば、設定管理もシンプルになります。

結合度の面では、Pull モデルの方がバックエンドとの結合度がはるかに低くなります。バックエンドが理解できるインターフェイスを提供するだけで済み、どのバックエンドに接続するか、バックエンド側でどのメトリックが必要かを気にする必要がありません。役割分担も比較的明確で、アプリケーション開発者は必要なメトリックを公開し、SRE（モニタリングシステム管理者）がそのメトリックを取得します。Push モデルは結合度が高く、アプリケーション側でバックエンドのアドレスと認証情報を設定する必要があります。ただし、ローカル Push エージェントを活用すれば、アプリケーションはローカルアドレスに Push するだけでよいため、コストは比較的低くなります。

運用保守とコストの比較

リソースコスト

全体コストの面では両方式に大きな差はありませんが、負担の観点から見ると違いがあります。

1. Pull モデルの主要なリソース消費はモニタリングシステム側に集中し、アプリケーション側のコストは低くなります。

2. Push モデルの主要なリソース消費は Push 側と Push エージェント側にあり、モニタリングシステム側の消費は Pull モデルより大幅に少なくなります。

運用保守コスト

運用保守の観点では、Pull モデルの方がコストが高くなります。Pull モデルで運用保守が必要なコンポーネントは、各種 Exporter、サービス検出、Pull エージェント、モニタリングバックエンドです。Push モデルで必要なのは、Push エージェント、モニタリングバックエンド、構成センター（オプション、通常はモニタリングバックエンドと同じ場所にデプロイ）のみです。

ここで注目すべき点は、Pull モデルではサーバー側からクライアントに能動的にリクエストを送信するため、ネットワーク面でクラスター間の接続とアプリケーション側のネットワーク保護 ACL を考慮する必要があることです。Push のネットワーク接続と比較すると、Pull のネットワーク接続は複雑です。Push は、サーバーが各ノードからアクセス可能なドメイン名または VIP を提供するだけで済みます。

Pull と Push の選択方法

現在のオープンソースソリューションでは、Pull モデルの代表は Prometheus ファミリーです（「ファミリー」と呼ぶ理由は、デフォルトのシングルノード Prometheus はスケーラビリティが限定的で、コミュニティには Thanos、VictoriaMetrics、Cortex など多くの Prometheus 分散ソリューションが存在するためです）。Push モデルの代表は InfluxDB の TICK（Telegraf、InfluxDB、Chronograf、Kapitor）スタックです。これら 2 つのソリューションにはそれぞれメリットとデメリットがあります。クラウドネイティブの文脈では、CNCF と Kubernetes の推進により Prometheus が普及するにつれ、多くのオープンソースソフトウェアが Prometheus 形式の Pull ポートをサポートするようになりました。一方で、設計上 Pull ポートを公開しにくいシステムも多く、そうしたシステムには Push エージェントでの監視が合理的です。

ただし、アプリケーション自体が Pull と Push のどちらを採用すべきかについては、一概に結論が出ていません。具体的な選択は企業の状況に基づく必要があります。たとえば、クラスターのネットワークが複雑な場合は Push が比較的シンプルです。短生命周期のアプリケーションが多い場合は Push 方式が必要です。モバイルアプリケーションは Push モードしか使用できません。システム自体が Consul でサービス検出を行っている場合は、Pull ポートを公開するだけで簡単に実装できます。

したがって、企業内部のモニタリングシステムにとって最適なソリューションは、Pull と Push の両方の機能を備えることです。

1. ホスト、プロセス、ミドルウェアの監視には Push エージェントを使用する。

2. Kubernetes など、Pull ポートを直接公開しているものには Pull モードを使用する。

3. アプリケーションは実際のシナリオに応じて Pull または Push を選択する。

Pull と Push に対する SLS の戦略

SLS は現在、ログ、メトリック、トレースの統一保存と分析をサポートしています。時系列モニタリングソリューションは Prometheus のフォーマット標準と互換性があり、標準的な PromQL 構文も提供しています。数十万の SLS ユーザーに対応するため、アプリケーションシナリオは大きく異なる可能性があり、単一の Pull または Push ですべてのユーザーニーズを満たすことはできません。そのため、SLS は Pull と Push の選択において単一の路線に従うのではなく、Pull と Push の両モデルと互換性を持っています。さらに、オープンソースコミュニティとエージェントに対して、SLS の戦略はクローズドなエコシステムを構築するのではなく、オープンソースエコシステムと完全に互換性を持つことです。

1. Pull モデル：Prometheus の Pull Scrap 機能と完全に互換性があります。Prometheus の Remote Write を使用して Prometheus を Pull エージェントとして利用できます。Prometheus と同等の Scrap 機能を持つ VMAgent も同様に使用できます。SLS 独自のエージェントである Logtail でも Prometheus の Scrap 機能を実現できます。

2. Push モデル：Telegraf は現在、業界で最も充実したモニタリング Push エージェントエコシステムです。SLS の Logtail には Telegraf が内蔵されており、Telegraf のすべてのモニタリングプラグインをサポートできます。

VMAgent、Prometheus、ネイティブ Telegraf などの Pull エージェントと比較して、SLS はさらに、最も必要性の高いエージェント構成センターとエージェントモニタリング機能を提供します。各エージェントの収集設定を管理し、サーバー側でこれらのエージェントの稼働状況を監視できるため、運用保守コストを可能な限り削減できます。

したがって、SLS でモニタリングソリューションを構築する実際の手順は非常にシンプルです。

1. SLS コンソール（Web ページ）でモニタリングデータを保存する MetricStore を作成する。
2. Logtail エージェントをデプロイする（一行のコマンド）。
3. コンソール上でモニタリングデータの収集設定を行う（Pull と Push の両方を利用可能）。