Kubernetesクラスタ設計・運用実践ガイド

第9章：監視・ログ・アラート設計

運用の成否は「観測できるか」で決まります。
本章では、SLI/SLO を起点に、メトリクス/ログ/アラートを最小の標準として定義し、ノイズを抑えつつ復旧に繋がる設計の論点を整理します。

学習目標

  • SLI/SLO とアラート設計の関係（エラーバジェット、重要度）を説明できる
  • 監視対象（Control Plane/Node/アドオン/ワークロード）を体系的に棚卸しできる
  • ログの収集/保持/アクセス制御（監査含む）を標準化できる
  • アラートのノイズ制御（重複、抑制、Runbook 連携）の方針を定義できる

扱う範囲 / 扱わない範囲

扱う範囲

  • SLI/SLO を起点にした設計（何を測るか、何で起こすか）
  • メトリクス/ログ/イベント/監査ログの位置付け
  • アラートの重要度設計（Sev、オンコール、通知経路）
  • ダッシュボード/Runbook との接続（復旧に繋がる形）

扱わない範囲

  • 特定ツール（Prometheus/Loki 等）の導入手順やチューニングの詳細
  • アプリケーション内部（ビジネスメトリクス）の設計

SLI/SLO を起点にする

監視は「計測できる」だけでは不十分で、運用判断（起こす/起こさない）に繋がる必要があります。

  • SLI: 信頼性を表す指標（例: エラーレート、レイテンシ、可用性）
  • SLO: 目標値（例: 月次の可用性 99.9%）
  • エラーバジェット: 目標から許容される失敗の枠（変更速度とリスクの調整に使う）

アラートは「SLO に対して意味があるもの」を優先し、ノイズ（actionable でない通知）を削減します。

監視対象の棚卸し（最小セット）

プラットフォーム運用では、以下の層で対象を整理すると抜け漏れが減ります。

  • Control Plane: API Server、Scheduler、Controller Manager、（自前の場合）etcd
  • Node: kubelet、ランタイム、ディスク/メモリ/ネットワーク
  • 基盤アドオン: DNS（CoreDNS）、CNI、CSI、Ingress Controller
  • ワークロード共通: スケジューリング失敗、Pod の異常再起動、依存先障害

ログ設計（収集/保持/権限）

ログは「復旧の一次情報」であり、収集されていないと切り分けができません。

  • 収集対象: Control Plane/Node/アドオン/ワークロード（最低限の分類）
  • 保持: 期間は規制/要件に依存します（運用要件として明文化）
  • 検索性: 相関（request id、trace id、tenant 情報）を持てる形式を推奨
  • 権限: 監査ログやアプリログは機微情報（PII 等）を含み得るため、閲覧権限と監査を定義

補足:

  • Kubernetes の Events は永続ではありません。重要事象は収集して検索可能にします。
  • 監査ログ（Audit）はセキュリティ運用（第7章）と一体で設計します。

アラート設計（ノイズ制御）

アラート設計は「検知」ではなく「復旧」を目的にします。

  • 重要度（Sev）を定義し、オンコール対象と通知経路を分けます（深夜通知の基準を明文化）。
  • 重複抑制（dedup）と抑制条件（silence）を運用に組み込みます。
  • アラートには Runbook へのリンクを付与し、切り分けの初動を標準化します（第11章、付録B）。

最小メトリクス/アラートの型（テンプレ）

SLI/SLO はワークロードの指標と直結しますが、プラットフォーム運用では「クラスタ共通で最低限そろえる型」を先に決めると、欠測や盲点を減らせます。

補足:

  • ここでの例はツール非依存です（メトリクス名は環境により異なります）。
  • 重要度（Sev）は組織により定義が異なるため、まず「起こす/起こさない基準」と「通知経路」を明文化してください。
対象 観測（型） 代表アラート（型） Sev（例） 一次対応（Runbook）
API Server 可用性/エラーレート/レイテンシ/飽和 到達不可、5xx 急増、P99 レイテンシ上昇 Sev1-2 付録B（API Server）、第11章
etcd 容量/レイテンシ/バックアップ結果 容量逼迫、レイテンシ継続、バックアップ失敗 Sev1-2 付録B（etcd）、第3章
Node Ready/Pressure/再起動 NotReady、DiskPressure、再起動頻発 Sev2 付録B（Node）、第4章
CoreDNS 失敗率/レイテンシ/欠測 失敗率上昇、レイテンシ上昇、欠測 Sev2-3 付録B（CoreDNS）、第5章
Ingress Controller 5xx/レイテンシ/欠測、Controller 健全性 到達性低下、5xx 急増、Controller CrashLoop Sev2 付録B（Ingress）、第5章
CNI Pod ネットワーク到達性/欠測、ノード側エラー Pod 間/Service 到達性低下、IP 枯渇、CNI エラー増加 Sev2 第5章、第11章
CSI/Storage Provision/Attach 失敗、I/O レイテンシ/欠測 PVC/PV が Pending、Attach 失敗、I/O 劣化 Sev2 付録B（ストレージ）、第6章
Scheduler/Controller Manager（自前の場合） Leader/ヘルス/欠測 リーダー選出異常、処理遅延、欠測 Sev2 第2章、第11章

アラート定義の最小テンプレ

各アラートは「復旧に繋がる形」で、最低限のメタデータを揃えます。

  • 目的（何を守るか）: 対応する SLI/SLO と影響（顧客影響/データ影響）
  • 条件（何で起こすか）: しきい値、期間、抑制条件（メンテウィンドウ等）
  • 重要度（Sev）/通知経路: ページ/チャット/チケットの使い分け
  • Runbook: まず見るダッシュボード、一次対応手順、エスカレーション先（付録B・第11章）

実務チェック観点（最低5項目）

  • SLI/SLO が定義され、アラートは SLO と接続して優先順位付けされている
  • Control Plane/Node/基盤アドオンを含む最小監視セットが整備され、欠測（収集失敗）を検知できる
  • ログ（イベント/監査含む）の収集/保持/検索性/アクセス制御が明文化され、監査証跡が残る
  • アラートの重要度（Sev）とオンコール体制が整備され、ノイズ制御（重複/抑制）が運用されている
  • アラートと Runbook/Playbook が接続され、復旧手順が継続的に改善されている（ポストモーテム反映）

よくある落とし穴

  • 「監視ツールを入れた」だけで満足し、SLO と結びつかず通知過多で運用が疲弊する
  • ログの閲覧権限/監査を設計せず、機微情報の取り扱いでコンプライアンスリスクが顕在化する

まとめ / 次に読む

Edit this page on GitHub