複雑な環境を監視するにはPrometheusでは不十分な理由

Prometheusだけでは複雑な環境を監視するには不十分である理由

現代のシステムは、何年も前のものとは大きく異なって見えます。開発組織は、従来のモノリシックなシステム構築から離れ、高度に分散化されたインフラストラクチャ上で動作する コンテナ化されたアプリケーション の開発へと移行しています。

この変更によりシステムは本質的に耐障害性を高めた一方で、全体的な複雑性の増加により、問題発生時にその根本原因を効果的に特定し対処することがより重要かつ困難になりました。

この課題の解決策の一部は、サービスとインフラの健全性を効果的に監視できるツールやプラットフォームを活用することにあります。その目的で、本記事ではサービスとインフラのPrometheus監視におけるベストプラクティスを解説します。さらに、今日の複雑で高度に分散化されたシステム環境を監視するには、Prometheusだけでは不十分である理由についても概説します。

Prometheusとは

Prometheusは、クラウドネイティブのメトリクス監視のために2012年にSoundCloudによって最初に開発された オープンソースの監視およびアラートツールキット です。

監視と可観測性 においては、主に3つのデータタイプがあります：ログ、メトリクス、トレース。メトリクスは、時系列データにおける サービスレベル目標（SLO）と サービスレベル指標（SLI）を追跡するためのデータストップウォッチとして機能します。

高カーディナリティのメトリクスは、ラベルのユニークな組み合わせ（例：user_id、region）を多数有するため、Prometheusのストレージとクエリ性能に負荷をかける可能性があります。しかし、多くの顧客は 可観測性 環境にもっと多くの機能を求めており、最近ではほとんどの組織が OpenTelemetry を採用してコレクターを統一し、これら3つのデータソースすべてからデータを収集しています。

Prometheusで監視できるもの

組織はPrometheusモニタリングを活用し、サービスとインフラストラクチャのパフォーマンスに関するメトリクスデータを収集します。ユースケースに応じて、PrometheusメトリクスにはCPU使用率、メモリ使用量、総リクエスト数、秒間リクエスト数、リクエストカウント、例外発生件数などのパフォーマンス指標が含まれます。効果的に活用すれば、収集されたメトリクスデータは組織がシステムの問題をタイムリーに特定する支援となります。

Prometheusサーバーアーキテクチャ

プロメテウスアーキテクチャは、実際の監視機能を実行するPrometheusサーバーの中核を成します。Prometheusサーバーは、時系列データベース、データ取得用のワーカー、HTTPサーバーという3つの主要コンポーネントで構成されます。

時系列データベース

このコンポーネントはメトリクスデータの保存を担当します。このデータは時系列として保存され、データベース内では、同一のメトリックとラベル付きディメンションのセットに属する、タイムスタンプ付きのデータポイントの系列として表現されます。

データ取得用ワーカー

このコンポーネントはその名の通り、アプリケーション、サービス、その他のシステムインフラストラクチャコンポーネントといった「ターゲット」からメトリクスを取得します。その後、収集したメトリクスを時系列データベースにプッシュします。データ取得ワーカーは、ターゲット上のHTTPエンドポイント（Prometheusインスタンスとも呼ばれる）をスクレイピングすることでこれらのメトリクスを収集します。

デフォルトでは、メトリクスエンドポイントは < ホストアドレス >/metricsです。対象を監視するには、Prometheus エクスポーター を使用して Prometheus を設定します。エクスポーターの本質は、ターゲットからメトリクスを取得し、適切にフォーマットした上で /metrics エンドポイントを公開するサービスです。これによりデータ取得ワーカーがデータを取得し、時系列データベースに保存できます。スクレイピングできないジョブからメトリクスをプッシュするには、Prometheus Pushgateway を使用します。これにより、短命なサービスレベルのバッチジョブから生成される時系列データを、Prometheus がスクレイピング可能な中間ジョブにプッシュできます。

HTTP サーバー

このサーバーは、時系列データベースからデータを取得するために、Prometheusクエリ言語（ PromQL）によるクエリを受け付けます。HTTPサーバーは、PrometheusグラフUIや Grafana などのデータ可視化ツールと連携することで、開発者やIT担当者がこれらのメトリクスを人間にとって有用な形式でクエリし可視化するためのインターフェースを提供します。

Prometheus アラートの管理

Prometheus Alertmanagerについてもここで触れておく価値があります。Prometheusの設定内でルールを設定し、超過時にアラートを発動させる閾値を定義できます。閾値を超過すると、PrometheusサーバーがアラートをAlertmanagerに送信します。Alertmanagerは、重複排除、グループ化を行い、これらのアラートをメールやその他のアラート連携機能を通じて適切な担当者にルーティングします。

なぜPrometheusだけでは不十分なのか

ご存知の通り、現代の開発アーキテクチャは10年以上前のものに比べてはるかに複雑化しています。今日のシステムには、Kubernetesクラスターのようにコンテナ化されたアプリケーションやサービスを実行する多数のサーバーが含まれています。これらのサービスは疎結合であり、エンドユーザーに機能を提供するために相互に呼び出されます。アーキテクチャ的には、これらのサービスは分離され、複数のクラウド環境で実行されることもあります。こうしたシステムの複雑性は、障害の原因を不明瞭にする効果をもたらす可能性があります。

組織はこの課題に対処するため、システム動作に関する詳細な洞察を必要としており、 ログイベントデータの収集と集約 がこの取り組みにおいて極めて重要です。このログデータはパフォーマンス指標と相関させることが可能であり、組織が効率的な 根本原因分析 に必要な洞察と文脈を得ることを可能にします。Prometheusはメトリクスを収集しますが、ログデータは収集しません。したがって、単独では効果的な インシデント対応 を支援するのに必要な詳細レベルを提供しません。

さらに、Prometheusは大幅なスケールアップ時に課題に直面します。これは、現代の高度に分散化されたシステムでは避けがたい状況です。Prometheusは元々、複数のインスタンスからメトリクスをクエリし集計するよう設計されていません。そのように設定するには、組織のPrometheusデプロイメントに追加の複雑さを加える必要があります。これにより、システム全体の包括的な可視化プロセスが複雑化し、これはインシデント対応を効率的に行う上で極めて重要な要素です。

最後に、Prometheusはメトリクスデータを長期間保持するよう設計されていません。複雑な環境を管理する組織にとって、この種の履歴データへのアクセスは極めて貴重なものです。例えば、組織はこれらのメトリクスを分析し、数か月あるいは1年単位で発生するパターンを検出することで、特定の期間におけるシステム利用状況を把握したいと考えるかもしれません。こうした知見は、システムが限界に達する可能性がある際の拡張戦略を決定づける可能性があります。

Kubernetes監視用統合データ収集

PrometheusはSLOやSLI向けの高レベルメトリクス収集に優れたツールですが、 サイト信頼性エンジニア やセキュリティアナリストは、何が具体的に問題だったのかを特定するためにログを詳細に分析する必要があります。そのため、ログ、メトリクス、トレースといったあらゆるデータタイプを統合的に収集するテレメトリが鍵となります。私たちは、最善の デジタル顧客体験 を確保するために、革新を起こし最新のベストプラクティスを活用するため、時代遅れのレガシープロセスや考え方を捨て去る必要があります。

これらの課題はすべて、 Sumo LogicのOpenTelemetry Collector による統合 Kubernetes監視 を活用し、 最新のHelm Chart を設定することで最適に対処できます。さらに、 Sumo LogicのOtel Remote Management を利用すれば、コレクターの設定と管理にかかる時間を節約できます。このコレクターと並行してPrometheusデータを集約することは可能ですが、インフラストラクチャが特定の専門的なスキルセットを必要とする場合を除き、メトリクスのミドルウェアとしてPrometheusを使用する理由は存在しません。例えば、PromQLの知識が必要な場合や、Sumo Logicの監視環境では利用できない特定のヒストグラムが必要な場合などが該当します。

OpenTelemetryを標準として採用することで、収集フットプリントを縮小し、効果的なセキュリティと監視のベストプラクティスを実現するための計測設定にかかる時間を節約できます。

詳細を知りたい方は、 Kubernetes監視のベストプラクティスをご確認ください。

FAQs

根本原因分析の結果は常に正確ですか？+

必ずしもそうとは限りません。分析の正確性は、データの質、分析を行う個人の専門性、および調査プロセスの徹底性に依存します。ログデータは 最も細かいレベル のデータであり、根本原因分析において最も有用かつ正確な情報源となります。

Sumo Logicと他のKubernetes監視ソリューションとの違い+

Kubernetesワークロードには多くの問題が発生する可能性があり、現代的なアプリケーション監視ツールは、どのポッドとノードの組み合わせに問題が発生しているかを特定できなければいけません。次に、関連するコンテナログを詳細に調査し、問題の根本原因を特定します。理想的には、Kubernetesインフラストラクチャの障害は、コンテナメトリクス、ノードメトリクス、リソースメトリクス、Kubernetesクラスタのログおよびトレースデータをヒストグラムやチャートで可視化できる監視ツールで把握すべきです。

従来の監視ツールはサーバーベースの手法を使用しており、今日のマイクロサービスアーキテクチャには適合しません。お客様のチームは、ポッド、コンテナ、ノードレベルにおけるインフラストラクチャの問題と、深刻な顧客問題やセキュリティ問題を関連付けるために貴重な時間を浪費しています。Sumo Logicはこのモデルを根本から覆しました。

Sumo Logicを使用すると、Kubernetes環境をログ、メトリクス、イベントの形で様々な階層構造で表示でき、選択した視点からクラスタを把握できます。たとえば、ネームスペースなどのネイティブKubernetesメタデータを使用して、特定のネームスペースに関連付けられたすべてのポッドのパフォーマンスを可視化できます。

マルチクラウド環境におけるKubernetesデプロイメントの監視における、特定の課題や制限とは+

測定すべきKubernetesのメトリクス+

Kubernetesクラスタを監視するための重要な指標は数多く存在します。監視はクラスターレベルとポッドレベルの2つのレベルで行われます。クラスタ監視は、Kubernetesクラスタ全体の健全性を追跡し、ノードが適切に機能し適切な容量で動作しているか、ノード上で実行されているアプリケーションの数、およびクラスタのリソース利用状況を検証します。ポッド監視は、リソース使用率、アプリケーションおよびポッドのレプリケーション、オートスケーリング指標など、個々のポッドのメトリクスに影響を与える問題を追跡します。

クラスタレベルでは、クラスタを実行するために必要なクラウドリソースを決定するため、利用可能で健全なノード数を測定する必要があります。また、ノードが使用するコンピューティングリソース（メモリ、CPU、帯域幅、ディスク使用率など）を測定し、クラスタ内のノードのサイズや数を増減させるべきかどうかを判断する必要があります。

ポッドレベルでは、3つの主要な指標があります。

コンテナ: ネットワーク、CPU、メモリ使用量

アプリケーション: アプリケーション固有であり、そのビジネスロジックに関連するもの

ポッドの健全性と可用性：オーケストレーターが特定のポッドをどのように処理するか、健全性チェック、ネットワークデータ、進行中のデプロイメント。