Amazon Managed Service for Prometheus によるコンテナモニタリング - EKS メトリクスの収集と分析
EKS/ECS のメトリクスを Prometheus 互換で収集し、PromQL でクエリする。Managed Grafana との統合でコンテナ監視基盤を構築する手法を紹介します。
Managed Prometheus の概要
Managed Service for Prometheus は Prometheus 互換のマネージドモニタリングサービスです。Prometheus サーバーのプロビジョニング、スケーリング、ストレージ管理、高可用性構成が自動化され、メトリクスの収集とクエリに集中できます。Prometheus のリモートライト API でメトリクスを送信し、PromQL でクエリを実行します。既存の Prometheus エクスポーター、Grafana ダッシュボード、アラートルールをそのまま移行できます。
EKS との統合
EKS クラスタからのメトリクス収集は ADOT (AWS Distro for OpenTelemetry) コレクターを DaemonSet としてデプロイするパターンが標準的です。ADOT コレクターが各ノードの kubelet、cAdvisor、kube-state-metrics からメトリクスをスクレイプし、Managed Prometheus のリモートライトエンドポイントに送信します。IRSA (IAM Roles for Service Accounts) で ADOT コレクターに Managed Prometheus への書き込み権限を付与します。Prometheus Operator を使用している場合は、ServiceMonitor と PodMonitor の設定をそのまま維持し、リモートライトの送信先を Managed Prometheus に変更するだけで移行が完了します。
PromQL とアラート
PromQL で収集したメトリクスをクエリし、 Managed Grafana でダッシュボードを構築します。 CPU 使用率、メモリ使用率、 Pod の再起動回数、リクエストレイテンシなどの標準的な Kubernetes メトリクスに加え、アプリケーション固有のカスタムメトリクスも収集・可視化できます。アラートマネージャーで PromQL ベースのアラートルールを定義し、 SNS トピックに通知を送信できます。メトリクスは 150 日間保持されるため、長期的なキャパシティプランニングやトレンド分析にも活用できます。 コンテナ監視の運用設計を検討するうえで関連書籍 (Amazon)が参考になります。
Managed Prometheus の料金
Managed Prometheus の料金はメトリクスの取り込み量、ストレージ、クエリで構成されます。取り込みは最初の 20 億サンプル/月が 1,000 万サンプルあたり約 0.90 ドルです。ストレージは 1 GB あたり月額約 0.03 ドルで、150 日間保持されます。クエリは処理したサンプル数に基づき、1,000 万サンプルあたり約 0.10 ドルです。セルフホストの Prometheus サーバーと比較すると、EC2 インスタンスの運用コストとストレージ管理の手間が不要になる分、中規模以上の環境ではマネージドサービスの方がトータルコストが低くなる傾向にあります。
ECS や自己管理クラスタからの収集
メトリクスの送信元は EKS に限りません。ECS では ADOT コレクターをサイドカーコンテナとしてタスクに組み込み、アプリケーションが公開する Prometheus 形式のメトリクスをスクレイプして送信します。EC2 上で自己管理している Prometheus からも、リモートライトの送信先を Managed Prometheus のエンドポイントに向けるだけで移行できます。オンプレミスや他環境で動くワークロードでも、リモートライトに対応していれば集約先として利用でき、複数環境に散らばったメトリクスを 1 か所に統合して横断的に監視できます。
Managed Grafana との連携
可視化は Managed Grafana との組み合わせが定番です。Managed Grafana のワークスペースを作成し、データソースとして Managed Prometheus を登録すると、PromQL で書いたパネルをそのまま表示できます。認証は IAM Identity Center や SAML と連携し、組織のシングルサインオンでアクセスを制御します。既存の Grafana ダッシュボードは JSON 定義をインポートするだけで移行でき、ツールの学習コストを抑えられます。Grafana 側のアラートと Prometheus 側のアラートルールは役割を分担させ、通知が重複しないように整理すると運用が安定します。
アラートとレコーディングルールの設計
アラートは、Managed Prometheus に組み込まれたアラートマネージャーで定義します。PromQL の条件式でしきい値を設定し、発火したアラートを SNS 経由で通知します。頻繁に評価する重いクエリは、レコーディングルールであらかじめ集計結果を別メトリクスとして保存しておくと、ダッシュボードやアラートの評価が高速になります。アラートは症状ベースで設計するのが基本で、CPU 使用率そのものよりも、レイテンシの悪化やエラー率の上昇といったユーザー影響に直結する指標を監視対象にすると、ノイズの少ない実用的な通知になります。
マルチアカウントとコスト最適化
大規模環境では、ワークスペースを環境やチーム単位で分割すると、権限とコストの境界が明確になります。クロスアカウントでメトリクスを集約する場合は、送信側に IAM ロールを引き受けさせて中央のワークスペースに書き込みます。取り込み量はサンプル数に比例して課金されるため、不要なメトリクスを送らないことと、ラベルのカーディナリティ (値の組み合わせ数) が膨らまないように設計することが、コスト管理の最大の要点です。高カーディナリティなラベルは取り込み量を急増させるため、収集対象を必要なものに絞り込みます。
まとめ
Managed Prometheus は Prometheus 互換のマネージドモニタリングサービスで、コンテナワークロードのメトリクス収集に最適です。ADOT コレクターで EKS からメトリクスを自動収集し、PromQL でクエリし、Managed Grafana で可視化する統合パターンが標準的です。