現代のシステムは、何年も前のものとは大きく異なって見えます。開発組織は、従来のモノリシックなシステム構築から離れ、高度に分散化されたインフラストラクチャ上で動作するコンテナ化されたアプリケーションの開発へと移行しています。
この変更によりシステムは本質的に耐障害性を高めた一方で、全体的な複雑性の増加により、問題発生時にその根本原因を効果的に特定し対処することがより重要かつ困難になりました。
この課題の解決策の一部は、サービスとインフラの健全性を効果的に監視できるツールやプラットフォームを活用することにあります。その目的で、本記事ではサービスとインフラの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監視のベストプラクティスをご確認ください。
