Kubernetes(K8s)監視の始め方【2026年】4層の指標とツール選定 | Guance

Kubernetes の監視は、コントロールプレーン・ノード・ワークロード(Pod/コンテナ)・アプリケーションの4層を、それぞれ別の指標と道具で見ることです。 1つのツールで全部見ようとするより、層ごとに「何を見て、どこにアラートを出すか」を決めるのが失敗しない進め方です。この記事は、層別の主要指標から、metrics-server と Prometheus の役割分担、最低限のアラート、ツール選択肢までを順に解説します(Kubernetes の基礎自体は「Kubernetesとは」を参照)。

なぜ Kubernetes の監視は難しいのか

従来のサーバー監視と決定的に違うのは、監視対象が静的でないことです。Pod は再作成で名前も IP も変わり、オートスケールで数も変わります。「3番サーバーのCPUが高い」という監視は成り立たず、代わりに「どのワークロードが、なぜ、どのくらいリソースを使っているか」をラベル(タグ)で追う設計が必要です。

監視の4層と主要指標

層	見るもの	主要指標
コントロールプレーン	クラスタの頭脳	API レイテンシ/エラー率、etcd コミット遅延
ノード	実マシンの健康	CPU/メモリ/ディスク圧力、kubelet 状態
ワークロード	Pod・Deployment	再起動回数、OOMKilled、Pending Pod、CPU スロットリング
アプリケーション	サービスの応答	RED(Rate/Errors/Duration)、分散トレース

層ごとのポイントだけ押さえます。

コントロールプレーン: マネージド(EKS/GKE/AKS)なら運営はクラウド側ですが、API の遅延とエラー率は自分で見るべきです。「デプロイが遅い」「kubectl が重い」の原因切り分けに直結します。
ノード: メモリ圧力(MemoryPressure)とディスク圧力(DiskPressure)が Pod の追い出し(eviction)の引き金です。
ワークロード: 障害の入口はほぼここ。再起動ループ、OOMKilled、Pending の3つは最優先でアラート化します。
アプリケーション: インフラが正常でもアプリが遅ければユーザー影響は出ます。RED 指標とトレースは APM の領域で、「APMとは」が詳しいです。

道具の役割分担 — metrics-server、Prometheus、kube-state-metrics

初心者が混同しやすい3つを整理します。

metrics-server: リソース使用量(CPU/メモリ)を軽量に集計。HPA(オートスケール)のデータ源であり、kubectl top の中身。監視ツールではなく、リアルタイムの現在値だけを持ちます。
Prometheus: 時系列を蓄積・クエリ・アラートできる本格監視基盤。過去との比較や「〇分間この状態が続いたら通知」はこちら。
kube-state-metrics(KSM): Deployment の望ましい数と現在の数、Pod のフェーズなど「K8s オブジェクトの状態」を Prometheus 向けの指標に変換します。再起動回数や Pending の監視は KSM 経由です。

実務の標準構成は「metrics-server(オートスケール用)+ Prometheus + KSM(監視とアラート用)」の併用です。

最低限設定したいアラート5つ

Pod の再起動が短時間に増えた(CrashLoopBackOff の前兆)
OOMKilled の発生(メモリ制限と実使用量のミスマッチ)
Pending 状態の Pod が一定時間解消しない(リソース不足かスケジュール不可)
ノードの MemoryPressure / DiskPressure
API サーバーのエラー率と p99 レイテンシの悪化

ツールの選択肢

自前で Prometheus スタックを運用する道と、SaaS に任せる道があります。

選択肢	特徴	向いているチーム
Prometheus + Grafana(自前)	無料、自由度最高	運用できるエンジニアがいる
Datadog	統合が広い、導入が速い	予算より速度重視(料金構造はこちら)
New Relic	データ量課金で小さく始められる	規模が小さい、変動が大きい
Guance(观测云)	従量課金・日次精算、DataKit を DaemonSet で配るだけ	使った分だけ払いたい

どの道を選んでも、見る指標とアラートはこの記事の4層で共通です。ツール差は収集と運用の負担に出ます。トレースまで一気通貫で見たい場合の導入は「ddtrace クイックスタート」が最短です。

よくある質問

Q. Kubernetes 監視は無料で始められますか?
はい。metrics-server と Prometheus + Grafana は無料で始められます。コストがかかるのはデータの保管・可用性・運用の人件費で、SaaS はその負担を料金に換えたものです。

Q. まず何から監視すべきですか?
ワークロード層の「再起動・OOMKilled・Pending」の3つからです。ユーザー影響のある障害の多くがこの3つで早期に検知でき、設定も単純です。次にノードの圧力指標、最後にコントロールプレーンとアプリの RED を足します。

Q. Prometheus と metrics-server は両方必要ですか?
役割が違うため併用が標準です。metrics-server はオートスケールと kubectl top の現在値用、Prometheus は蓄積・クエリ・アラート用です。Prometheus があっても HPA は metrics-server を見ます。

Q. マネージド(EKS 等)でも監視は必要ですか?
必要です。コントロールプレーンの運営はクラウド側ですが、ノード・ワークロード・アプリケーションの監視は利用者の責任範囲です。マネージドでも「API の遅延」は自分で見ないと切り分けられません。

Q. 監視の費用はどのくらいかかりますか?
自前ならソフトウェアは無料で運用コストのみ、SaaS なら構成次第です。100 ホスト規模の例は「Datadog 料金の仕組み」に他社比較とともにあります。ツール選択より、まず4層の指標設計を先に決めるのがおすすめです。