現代のシステムは、何年も前のものとは大きく異なって見えます。開発組織は、従来のモノリシックなシステム構築から離れ、高度に分散化されたインフラストラクチャ上で動作するコンテナ化されたアプリケーションの開発へと移行しています。
この変更によりシステムは本質的に耐障害性を高めた一方で、全体的な複雑性の増加により、問題発生時にその根本原因を効果的に特定し対処することがより重要かつ困難になりました。
この課題の解決策の一部は、サービスとインフラの健全性を効果的に監視できるツールやプラットフォームを活用することにあります。その目的のため、本記事ではサービスとインフラストラクチャのPrometheus監視におけるベストプラクティスについて解説します。さらに、今日の複雑で高度に分散化されたシステム環境を監視するには、Prometheusだけでは不十分である理由についても概説します。
Prometheusとは
Prometheusは、クラウドネイティブのメトリクス監視のために2012年にSoundCloudによって最初に開発されたオープンソースの監視およびアラートツールキットです。
監視と可観測性においては、主に、ログ、メトリクス、トレースの3つのデータタイプがあります。メトリクスは、時系列データにおけるサービスレベル目標（SLO）とサービスレベル指標（SLI）を追跡するためのデータストップウォッチとして機能します。
高カーディナリティのメトリクスは、ラベルのユニークな組み合わせ（例：user_id、region）を多数有するため、Prometheusのストレージとクエリ性能に負荷をかける可能性があります。しかし、多くの顧客は可観測性環境にもっと多くの機能を求めており、最近ではほとんどの組織がOpenTelemetryを採用してコレクターを統一し、これら3つのデータソースすべてからデータを収集しています。
Prometheusで監視できるもの
組織はPrometheus監視を活用し、サービスおよびインフラストラクチャのパフォーマンスに関するメトリクスデータを収集します。ユースケースに応じて、PrometheusメトリクスにはCPU使用率、メモリ使用量、総リクエスト数、秒間リクエスト数、リクエストカウント、例外発生件数などのパフォーマンス指標が含まれる場合があります。効果的に活用すれば、収集したメトリクスデータは組織がシステムの問題をタイムリーに特定するのに役立ちます。
Prometheusサーバーアーキテクチャ
Prometheusアーキテクチャは、実際の監視機能を実行するPrometheusサーバーの中核をなします。Prometheusサーバーは、時系列データベース、データ取得用のワーカー、そしてHTTPサーバーといった、主に3つのコンポーネントで構成されています。
時系列データベース
このコンポーネントはメトリクスデータの保存を担当します。このデータは時系列として保存されます。つまり、データベース内では、同一のメトリックとラベル付きディメンションのセットに属する、タイムスタンプ付きのデータポイントの系列として表現されます。
データ取得用ワーカー
このコンポーネントはその名の通り、アプリケーション、サービス、その他のシステムインフラストラクチャコンポーネントといった「ターゲット」からメトリクスを取得します。収集したこれらのメトリクスを時系列データベースにプッシュします。データ取得ワーカーは、ターゲット上のHTTPエンドポイント（Prometheusインスタンスとも呼ばれる）をスクレイピングすることで、これらのメトリクスを収集します。
デフォルトのメトリクスエンドポイントは < hostaddress >/metrics です。対象を監視するために、Prometheusエクスポーターを使用して Prometheus を設定します。本質的に、エクスポーターはターゲットからメトリクスを取得し、適切にフォーマットし、/metrics エンドポイントを露出するサービスであり、これによりデータ取得ワーカーが時系列データベースへの保存のためにデータを取得できるようになります。スクレイピングできないジョブからメトリクスをプッシュするため、Prometheus Pushgateway を使用すると、短命なサービスレベルのバッチジョブから生成される時系列データを、Prometheus がスクレイピング可能な中間ジョブにプッシュできます。
HTTP サーバー
このサーバーは Prometheus クエリー言語 (PromQL) によるクエリーを受け付け、時系列データベースからデータを取り出します。HTTPサーバーは、PrometheusグラフUIやGrafanaなどのデータ可視化ツールと連携することで、開発者やIT担当者がこれらのメトリクスを人間にとって有用な形式でクエリし可視化するためのインターフェースを提供します。
Prometheus アラートの管理
ここでPrometheusアラートマネージャーについてご紹介します。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リモート管理を利用すれば、コレクターの設定と管理にかかる時間を節約できます。このコレクターと並行してPrometheusデータを集計することは可能ですが、インフラストラクチャが特定の専門的なスキルセットを必要とする場合を除き、メトリクスのミドルウェアとして使用する必要はありません。例えば、PromQLの知識や、Sumo Logicの監視環境では利用できない特定のヒストグラムの必要性など。
OpenTelemetryを標準として採用することで、収集フットプリントを縮小し、効果的なセキュリティと監視のベストプラクティスを実現するための計測設定にかかる時間を節約できます。
詳細の確認はこちらKubernetes監視のベストプラクティスを確認する。
