DOPモニタリングとロギング
企業がAmazon EKS（Elastic Kubernetes Service）上で30以上のマイクロサービスを運用しています。DevOpsチームはKubernetesクラスター全体のノード・Pod・コンテナレベルのCPU・メモリ・ネットワーク・ディスクI/Oメトリクスを一元的にCloudWatchで監視したいと考えています。また、EKSコントロールプレーンのログ（API Server、コントローラーマネージャー、スケジューラーなど）もCloudWatch Logsに集約したいと考えています。最も運用負荷が低くAWSネイティブな実装方法はどれですか？
APrometheusとGrafanaをEKSクラスター内に自前デプロイしてノード・Pod・コンテナのメトリクスを収集し、EKSコントロールプレーンログはFluentdで別途転送、CloudWatchダッシュボードにIframe埋め込みで統合する
自前のPrometheus/Grafanaは追加インフラの構築・運用管理負荷が高く、CloudWatchとの統合もIframe埋め込み程度で限定的です。コントロールプレーンログも別ツールが必要でAWSネイティブとは言えません。
BCloudWatch Container Insightsを有効化してエージェントとFluent BitをDaemonSetでデプロイし、メトリクスとログを自動収集、コントロールプレーンログはコンソールから有効化してCloudWatch Logsに送信する
✓ 正解
Container InsightsはエージェントとFluent BitをDaemonSetで展開しノード・Pod・コンテナのメトリクスとログを自動収集、コントロールプレーンログはコンソール有効化のみでCloudWatch Logsに送れる最も低運用負荷なネイティブ構成です。
CAWS X-RayデーモンをEKSのDaemonSetとしてデプロイして各Podのトレースを収集し、CloudWatch ServiceLensでクラスター全体を監視、コントロールプレーンログはCLIで有効化してCloudWatch Logsに送る
X-Rayは分散トレーシングが主目的で、ノードやPodレベルのインフラメトリクス収集には対応していません。コントロールプレーンログを送れても要件のメトリクス監視を満たせません。
DAmazon Managed Service for Prometheus（AMP）とAmazon Managed Grafana（AMG）を使い、PrometheusメトリクスをCloudWatchへ転送するカスタムエクスポーターを別途開発してコントロールプレーンログと統合する
AMP+AMGは有効な観測基盤ですが、CloudWatchへ転送するにはカスタムエクスポーターの開発が必要で運用負荷が高く、最もAWSネイティブかつ低運用負荷な方法ではありません。
解説
CloudWatch Container InsightsはEKS/ECSに対応したマネージドモニタリング機能です。eksctlやHelmで有効化すると、CloudWatchエージェントがDaemonSetとしてデプロイされノード・Pod・コンテナレベルのメトリクスを自動収集し、Fluent Bitがコンテナログを/aws/containerinsights/以下のロググループに転送します。EKSコントロールプレーンログはAWSコンソールまたはeksctlで有効化するだけでCloudWatch Logsに直接送信でき、追加のエージェントは不要です。
選択肢AのPrometheusとGrafanaは、CloudWatchとの統合が限定的で追加インフラの管理負荷が発生します。
選択肢CのX-Rayは、分散トレーシングが主目的であり、KubernetesノードやPodレベルのインフラメトリクス収集には対応していません。
選択肢DのAMP + AMG + カスタムエクスポーターは、有効な観測基盤ですが、CloudWatchへの転送に追加のカスタムエクスポーター開発が必要で、最もAWSネイティブかつ低運用負荷な方法ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →