こんにちはサイオステクノロジーの前田です。
インフラを作成し運用するときには監視を行います。Kubernetes環境でも同様に監視を行います。最近では監視にプラスして「オブザーバビリティ」という、いろいろな情報を収集していくケースがあり、運用の情報整理がどんどん複雑になってきています。今回はKubernetesの基本的な監視と、オブザーバビリティについて記載します。
従来の仮想マシンや物理サーバー環境と比較して、Kubernetes環境ではコンテナの頻繁な生成・破棄、動的なIP割り当て、分散されたアーキテクチャなどの特徴があります。これに伴い生成されるログやメトリクスデータの量が劇的に増加するため、既存通りの運用ということはあまり適切でないこともあり、適切な要件整理と最適なソリューション選定が必要となります。
Kubernetes オブザーバビリティとは
まず、混同されがちな「監視」と「オブザーバビリティ」を区別しましょう。
従来の「監視（Monitoring）」と「オブザーバビリティ」の違い
- 監視（Monitoring）： あらかじめ定義された異常（CPU高負荷、プロセスダウン等）が発生したことを検知・通知する受動的な仕組み。
- オブザーバビリティ（Observability）： システムの外部出力データ（メトリクス、ログ、トレース）から、内部の状態や未知のトラブルの根本原因を「探索・特定」できる能動的な能力。
大規模な構成や継続的な開発ではオブザーバビリティの仕組みを入れることは有効です。ただコンテナ利用の最初期から導入するのは目的が見えなくて無駄が多いものです。そのためKubernetesソリューション構築初期設定にはオブザーバビリティソリューションが全部入っていない方が一般的です。
オブザーバビリティの3大要素
オブザーバビリティを実現するには、以下の3つのデータを収集して連携させていきます。
|
データの種類 |
内容 |
主な対象例 |
|---|---|---|
|
メトリクス（Metrics） |
システムの数値を定期的に計測・集約した数値データ |
ホスト/コンテナのCPU・メモリ使用率、Podの再起動回数 |
|
ログ（Logs） |
システムやアプリケーションで発生したイベントの記録データ |
K8sイベントログ、コンテナ標準出力（stdout/stderr）、アクセスログ |
|
トレース （Traces） |
分散環境における一連のリクエスト処理経路を追跡するデータ |
マイクロサービス間のHTTP/gRPC呼び出し履歴、処理遅延箇所の特定 |
オブザーバビリティ利用時の注意点・課題
オブザーバビリティのデータ収集時には注意点や課題が発生します。よく発生する課題を下記に記載します。
- データの肥大化とコスト増： Kubernetes非利用時と比較してメトリクスやログの量が膨大になります。従来同等の保持期間・取得設定にすると、ストレージコストの増大や監視ソリューション側の処理遅延を引き起こします。ログが１日に１ノードあたり数十ＧＢになるケースもあるため、データ転送する対象やデータ量を検討する必要が有ります。
- データの保持期間と間引き（サンプリング）： 運用要件に合わせて、保持期間の設定（短期間保持、古いデータの自動削除）やテスト環境での試算を行う必要があります。ソリューションによってはデータの長期間保存に対応していないものも存在します。
代表的なソリューション
Kubernetesにおけるオブザーバビリティソリューションには、オープンソース（OSS）から商用SaaSまで多様なツールが存在します。
機能別の主要OSSソリューション
|
カテゴリ |
代表的なツール・ソリューション |
特徴 |
|---|---|---|
|
メトリクス収集・保管 |
Prometheus, VictoriaMetrics |
K8s標準のメトリクス収集基盤。大規模環境ではVictoriaMetrics等の長期保管向けエンジンの検討も有効。 |
|
ログ集約・管理 |
Fluent Bit, Fluentd, Grafana Loki |
軽量なFluent Bitで収集し、Lokiに保管。 |
|
分散トレーシング |
Jaeger, Grafana Tempo, OpenTelemetry |
リクエスト追跡。OpenTelemetry（OTel）を標準SDKとして活用する構成が増加。 |
|
可視化（ダッシュボード） |
Grafana |
メトリクス・ログ・トレースを一元化して可視化・相関分析する標準ツール。 |
プラットフォーム組み込みモニタリング
主要なコンテナプラットフォームでは、Prometheusを中心としたモニタリング機能がデフォルトまたはアドオンとして提供されています。
- OpenShift Monitoring: プラットフォーム構築時に標準でデプロイされる統合監視環境。
- Rancher Monitoring: クラスター構築後にワンクリックで設定・統合可能なモニタリングスタック。
Prometheus Operator
最小限かつ標準的なKubernetesモニタリング構成を構築・運用する際、OSSのPrometheus Operator が広く採用されています。Prometheusという場合はPrometheus Operatorではなくメトリクス収集・蓄積の機能のPrometheusを指します。しかし、単体で導入することよりも運用しやすいように連携しているPrometheus Operatorの形式でインストールされることの方が多いです。
Prometheus Operatorの主な構成コンポーネント
- Prometheus Server: メトリクスの収集（Pull型）、時系列データベースへの保存。
- Alertmanager: 条件に応じたアラートの集約・抑制・通知（Slack, メールなど）。
- node-exporter: ホスト（ノード）レベルのハードウェア・OSリソースのメトリクス出力。
- kube-state-metrics: Pod, Deployment, NodeなどKubernetesオブジェクトの状態メトリクス生成。
- Grafana: 収集されたメトリクスを可視化するダッシュボード。
おわりに
オブザーバビリティに関してKubernetes構成に慣れていない時点で多くの機能を導入した場合使いこなせないケースもあります。オブザーバビリティの導入については最初期はPrometheus Operatorを導入して、その後必要な機能を検討することがお勧めです。
