Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断

Kubernetesクラスタは、ノード・Pod・コンテナが動的に入れ替わるため、サーバー単体を前提にした従来の監視設計をそのまま持ち込むと破綻しがちです。本記事は、Kubernetes監視の対象をクラスタ・ノード・Pod・アプリケーションの4階層で整理し、Prometheusとkube-prometheus-stackによるメトリクス収集、GrafanaダッシュボードとLokiによるログ集約、そしてアラート閾値の設計基準までを実装者の目線で解説します。あわせて、マネージド監視サービスと自前構築のどちらを採るべきかを、クラスタ規模と体制の条件付きで示します。

まとめ：Kubernetes監視の標準構成とアラート設計の結論

Kubernetesのメトリクス監視は、Prometheus・Grafana・Alertmanagerを束ねたkube-prometheus-stackを土台にするのが現在の標準形です。kubelet内蔵のcAdvisorとkube-state-metricsがコンテナ実測値とオブジェクト状態を供給し、Grafanaのダッシュボードで可視化し、ログはGrafana Lokiまたはマネージドサービスへ集約します。この構成ならHelmチャート一式で導入でき、収集対象の追従はサービスディスカバリが自動で引き受けます。

アラートは「CPU使用率90%超」のようなリソース閾値を並べるのではなく、ユーザー影響に近い症状（エラー率・レイテンシ・再起動回数）へ寄せるのが結論です。リソース閾値は誤検知と通知疲れを生み、本当に必要な通知が埋もれるためです。監視基盤そのものについては、ノード20台未満で専任の基盤担当がいない体制なら自前のPrometheus運用を採用せず、Container InsightsやDatadogなどのマネージドへ寄せる判断を推奨します。根拠と適用条件は本文で順に示します。

Kubernetes監視の対象4階層と標準メトリクスコンポーネントの全体像

監視設計の最初の仕事は「何を見るか」の整理です。対象を階層で分けると、障害時にどの層から疑うかの順路が決まり、切り分けが速くなります。

クラスタ・ノード・Pod・アプリケーションの4階層で分ける監視対象

Kubernetes監視の対象は4階層に分かれます。クラスタ層ではAPIサーバーやetcdなどコントロールプレーンの応答と、スケジューリング可能なリソース残量を見ます。ノード層はCPU・メモリ・ディスク・ネットワークの使用状況と、kubeletの稼働状態が対象です。Pod・コンテナ層では再起動回数、OOMKilledの発生、CPUスロットリングの有無を追い、アプリケーション層でリクエストのエラー率とレイテンシを測ります。障害の症状はアプリ層に現れ、原因は下位層に潜むことが多いため、4階層を縦に貫いて見られる構成が求めるゴールです。PodやノードなどKubernetesの基本オブジェクトから確認したい場合は、Kubernetesの仕組みを初心者向けに解説した記事が前提整理に使えます。

metrics-serverとkube-state-metricsが担うデータの違い

Kubernetesのメトリクスは、供給元の役割を知らないと重複導入や欠落が起きます。コンテナのCPU・メモリ実測値はkubelet内蔵のcAdvisorが生成し、metrics-serverはそれを集約してkubectl topや水平オートスケーラ（HPA）に渡します。metrics-serverは直近値のみ保持し、履歴を保存しない点が要注意です。一方kube-state-metricsは、Deploymentのレプリカ数やPodのフェーズといった「オブジェクトの状態」をメトリクス化します。役割は下表のとおりです。

この表の4つに履歴保存の仕組みは含まれません。時系列で貯めて分析する層は、次章のPrometheusが受け持ちます。

Kubernetes監視とオブザーバビリティの違いと3つのテレメトリー

監視（モニタリング）は「既知の異常を検知する」営みで、あらかじめ決めた指標と閾値を見張ります。オブザーバビリティは「未知の異常を調査できる状態を作る」考え方で、メトリクス・ログ・トレースの3種類のテレメトリーデータを揃えることが土台です。メトリクスは傾向の把握と検知、ログは原因の特定、トレースはマイクロサービス間のどこで遅延したかの追跡と、答えられる問いが異なります。実務ではまずメトリクスとログの2本を整備すれば大半の障害対応が回り、トレースはサービス数が増えてから足す優先順位で構いません。

Prometheusとkube-prometheus-stackによる収集基盤の構成

メトリクスの収集・保存・アラート評価を担う中核がPrometheusです。Kubernetesと同じCNCF卒業プロジェクトで、クラスタ監視の事実上の標準として使われています（2026年7月時点の安定系列は3系）。

Prometheusのpull型収集とサービスディスカバリによる自動追従

Prometheusは監視対象へ自ら取得しに行くpull型で、各対象がHTTPで公開するmetricsエンドポイントを一定間隔でスクレイプします。Kubernetes環境で効くのがサービスディスカバリで、APIサーバーへ問い合わせてPodやServiceの一覧を取得し、増減した対象を設定変更なしで収集へ組み込む仕組みです。Podがオートスケールで何十個増えても監視設定を書き換えない、という性質は動的なクラスタと相性が良く、push型のエージェントを全対象へ配る方式より構成が単純になります。Prometheus Operatorを使う場合は、ServiceMonitorリソースを書くだけで収集対象を宣言的に追加できます。

kube-prometheus-stackで一括導入する構成要素と手順

個別に組むと手間の大きい監視一式は、Helmチャートのkube-prometheus-stackでまとめて導入するのが実務の定石です。Prometheus Operator・Prometheus本体・Alertmanager・Grafana・node-exporter・kube-state-metricsが一度に入り、Kubernetes向けの標準アラートルールとダッシュボードも同梱されます。導入の流れは次のとおりです。

1. Helmリポジトリにprometheus-communityを追加する
2. 保存期間・ストレージ容量・通知先をvaluesファイルで設計する
3. helm installで監視用namespaceへ展開する
4. アプリ固有の収集対象をServiceMonitorで追加する

初期状態でもノード・Pod層の監視は成立します。設計判断が要るのは保存期間とストレージ容量で、既定のまま本番へ出すとディスク枯渇で監視自体が止まる事故につながります。

PromQLとレコーディングルールによるリソース使用率の集計例

収集したメトリクスはクエリ言語PromQLで集計します。ノードのCPU使用率はnode_cpu_seconds_totalの増分から算出し、コンテナのメモリはOOMの判定に使われるcontainer_memory_working_set_bytesをリミット値と比べるのが定番です。ダッシュボードやアラートで同じ集計を何度も評価すると負荷が積み上がるため、頻用するクエリはレコーディングルールで事前計算し、結果を新しいメトリクスとして保存しておきます。kube-prometheus-stackには主要な集計ルールが同梱済みなので、まず同梱ルールの命名規則に沿って読み、足りない分だけ自作する進め方が安全です。

GrafanaダッシュボードとLokiによるログ集約の設計指針

収集したデータは、見る人と目的を決めて画面化しないと放置されます。この章では可視化とログの設計指針を扱います。

Grafanaダッシュボードへ最初に置く4つのゴールデンシグナル

ダッシュボードの軸には、Google SRE本が示す4つのゴールデンシグナル（レイテンシ・トラフィック・エラー・サチュレーション）を置きます。この4つはユーザー影響との距離が近く、どのサービスにも共通に適用できるためです。作り方の失敗パターンは、取得できるメトリクスを全部並べた「全部盛り」画面です。1画面1目的に絞り、障害対応用は4シグナルと直近の変化、キャパシティ計画用はノード資源の余力、と分けて作ります。Grafana（2026年7月時点の安定系列は12系）はkube-prometheus-stack同梱の公式ダッシュボードを持つため、ゼロから作らず同梱版を目的別に間引く方が早く運用に乗ります。

Grafana LokiとFluent Bitで組むログ集約経路の構成

Podのログは標準出力へ流し、ノード常駐のコレクタが拾って集約先へ送る構成が基本形です。コレクタには軽量なFluent BitやGrafana Alloyを各ノードへDaemonSetで配置します。集約先をGrafana Lokiにすると、ログ全文ではなくラベルだけを索引化する設計により保存コストを抑えられ、Grafana上でメトリクスと同じ画面からLogQLで検索可能です。メトリクスで異常時刻を特定し、同じ画面で該当Podのログへ降りる、という動線が短くなる点が採用理由です。Lokiの仕組みとLogQLの書き方はGrafana LokiとPrometheus連携の解説記事で詳しく扱っています。注意点はラベル設計で、Pod名のような高カーディナリティ値をラベルにすると索引が膨張して性能が落ちます。

OpenTelemetry計装によるトレース統合と段階導入の判断

マイクロサービスが増えると、どのサービス間で遅延が起きたかはメトリクスとログだけでは追い切れず、分散トレースが必要になります。計装の標準はOpenTelemetryで、アプリにSDKを組み込み、OTLPプロトコルでCollector経由の送出に統一すると、バックエンド（Tempo・Jaeger・各SaaS）を後から差し替えられます。仕様の全体像とPrometheusとの関係はOpenTelemetryの3つのシグナルを整理した記事を参照してください。導入順序は判断を言い切ります。サービス数が数個のうちはトレースを後回しにしてメトリクスとログへ投資し、サービス間呼び出しの障害切り分けに時間を取られ始めた段階で計装を始める、が費用対効果の高い順路です。

アラート閾値の設計基準とAlertmanagerによる通知疲れ対策

監視の価値はアラートの質で決まります。検知できない監視は論外ですが、実際の現場で多いのは逆で、鳴りすぎて無視される状態です。

CPU使用率90%アラート型の静的閾値が生む誤検知と見直し基準

「CPU使用率90%超で通知」という静的閾値は、Kubernetesでは誤検知の温床になります。コンテナのCPU使用率はresources.requests比かリミット比かノード比かで意味が変わり、リミット未設定なら分母すら定まりません。バッチ処理が一時的に張り付くのは正常動作で、逆にリミットに達していなくてもCPUスロットリングでレイテンシが劣化することもあります。見直しの基準は「そのアラートを受けて人が今すぐ行動するか」です。行動しない通知は削除するか、ダッシュボードでの観察へ格下げします。リソース系で残す価値が高いのは、OOMKilledの発生、再起動の繰り返し（CrashLoopBackOff）、ディスク残量、証明書期限といった、放置すると確実に障害へ進む指標です。

エラーバジェットとSLOバーンレートに基づくアラート判定の設計

ユーザー向けサービスの本丸は、SLO（サービスレベル目標）を起点にしたアラートです。たとえば可用性99.9%をSLOに置くと、月あたり許容できるエラー量（エラーバジェット）が定まり、その消費速度＝バーンレートで通知を判定します。Google SREワークブックの方式では、1時間窓でバーンレート14.4倍（数日でバジェットを使い切る速度）なら即時対応、6時間窓で6倍なら翌営業日対応、と重大度を分けます。瞬間的なスパイクでは鳴らず、ユーザー影響が積み上がる異常だけを拾えるのが利点です。適用条件も明確にします。SLOを定義できるのはリクエスト応答型のサービスであり、社内バッチや開発環境にこの方式を持ち込むのは過剰です。そこは前述のリソース系静的閾値で足ります。

Alertmanagerのグルーピング・抑制・サイレンスの設定実務

発報後の交通整理はAlertmanagerの仕事です。実務で効く設定は3つ。グルーピングは同一namespaceや同一アラート名の通知を1通にまとめ、ノード障害時に数十通が個別に届く事態を防ぎます。抑制（inhibition）は上位の障害が出ているとき下位のアラートを止める設定で、ノードダウン発報中はそのノード上のPodアラートを黙らせる、といった依存関係を表現できます。サイレンスは計画メンテナンス中の一時停止です。加えてルーティングで、criticalはオンコールの呼び出し、warningはチャット通知、と重大度別に配送先を分けます。この4点を入れるだけで通知量は体感で桁が変わり、アラート対応の心理的負荷が下がります。

マネージド監視サービスと自前Prometheus運用の採用判断基準

ここが本記事の独自の視点です。監視スタックは「組めるか」ではなく「維持できるか」で選びます。構築の技術記事は多くても、選定の損益分岐を条件で示した情報は多くありません。

Container Insightsなどマネージドに寄せるべき場面

結論から言えば、ノード20台未満のクラスタで、監視基盤を専任で見る担当がいないなら、自前のPrometheus運用は採用しないのが妥当です。CloudWatchのContainer Insights、Datadog、Grafana Cloudといったマネージドは、収集基盤の可用性・保存・バージョン追随を提供側が引き受けるため、チームはダッシュボードとアラート設計だけに集中できます。従量課金はメトリクス量に比例して増えますが、小規模のうちは基盤担当の人件費より安く収まるのが通例です。EKSを使っている場合の具体的な構成はADOTとContainer Insightsで計装するAWSオブザーバビリティの記事で詳しく扱っています。

kube-prometheus-stack自前運用が見合う規模と体制

自前構築が見合うのは条件が揃ったときだけです。目安は、複数クラスタを横断して監視する必要がある、メトリクス量の増加でSaaS課金が基盤運用の工数コストを上回った、データを外部へ出せない制約がある、の3つで、どれかに該当してから移行を検討します。長期保存はPrometheus単体の弱点のため、複数クラスタ集約や1年超の保持にはThanosやMimirを重ねる設計が前提です。体制面では、PromQLとAlertmanagerの設定を書ける担当が最低2名いることを条件にします。1名だけの属人運用は、その人の異動と同時に監視が塩漬けになる失敗パターンです。

アラート対応など監視基盤構築後に残る運用負荷と外部保守の使い方

監視は構築して終わりではなく、閾値の継続チューニング、ストレージ容量の管理、ExporterやチャートのバージョンアップとKubernetes本体の更新追随が定常負荷として残ります。夜間休日のアラート一次対応まで含めると、社内だけで回すには当番体制の設計が必要です。この定常部分を外部へ切り出す選択肢もあり、24時間監視を含むシステム保守運用・内製化支援のように、監視設計と一次対応を委託しながら段階的に内製へ移す形なら、担当1〜2名の体制でも本番運用が成立します。委託時は「どのアラートで誰が起きるか」の責任分界を契約前に文書化しておくと、運用開始後の齟齬を避けられます。

よくある質問

Kubernetes監視・モニタリングの設計と実装について、着手前によく挙がる疑問に答えます。

Kubernetesの監視は何から始めればよいですか？

最初はkube-prometheus-stackの導入から始めるのが近道です。Prometheus・Grafana・Alertmanagerと標準的なダッシュボード・アラートルールが一括で入り、ノードとPodの監視は初期状態で成立します。そのうえで、自アプリのエラー率とレイテンシの計測、ログ集約の整備、アラートの取捨選択へ順に進めると、投資した分だけ運用が楽になる順序で育てられます。

metrics-serverだけでは監視として不十分ですか？

不十分です。metrics-serverはkubectl topとオートスケール判定のために直近値を集約するコンポーネントで、履歴を保存せずアラート機能も持ちません。障害の予兆分析や事後調査には時系列データベースが要るため、Prometheusなどの監視基盤を別に用意します。両者は競合ではなく併用が前提です。

PrometheusとGrafanaはどう役割が違いますか？

Prometheusはメトリクスの収集・保存・アラート評価を担う時系列データベースで、Grafanaはそのデータを可視化するダッシュボードツールです。GrafanaはPrometheus以外にLokiやCloudWatchなど複数のデータソースを1画面に束ねられるため、メトリクスとログを横断して見る画面はGrafana側で作ります。セットで使うのが標準構成です。

アラートはどの指標に設定すべきですか？

ユーザー影響に近い順に、エラー率・レイテンシ・OOMKilledや再起動の繰り返し・ディスク残量・証明書期限が優先です。CPU使用率のような資源使用率そのものは、人が即時対応する指標としては誤検知が多いため、ダッシュボードでの観察に回します。ユーザー向けサービスでSLOを定義できるなら、バーンレート方式への移行が通知の質を上げます。

監視SaaSと自前構築はどちらを選ぶべきですか？

ノード20台未満で専任の基盤担当がいないなら、Container InsightsやDatadogなどのマネージドを選ぶ方が総コストは下がります。自前のkube-prometheus-stackが見合うのは、複数クラスタの横断監視・SaaS課金の逆転・データ主権の制約のいずれかが生じ、かつ監視基盤を書ける担当を2名以上確保できる場合です。

関連記事

• Kubernetes（クーベネティス）とは？読み方・K8sの意味から仕組みまで初心者向けに解説：本記事の前提となるPod・ノードなど基本オブジェクトを確認できます。
• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説：そもそもKubernetesを導入すべきかの全体判断はこちらで整理しています。
• Kubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断：監視と並ぶ運用設計の柱であるネットワーク層を実装視点で解説しています。
• Kubernetes永続化ストレージ入門｜PV・PVC・StorageClassの設計と運用の落とし穴：Prometheusの保存領域設計にも関わる永続化の仕組みを扱っています。
• Grafana Lokiとは？Prometheus連携・LogQL・導入方法をわかりやすく解説：本文で触れたログ集約基盤Lokiの導入手順を詳しく解説しています。