【Vol.03】Kubernetes環境の監視は難しい？
監視環境の構築ポイントを解説

Kubernetes環境を監視する場合、コンテナアプリケーションがどのノードで稼働しているか外部から状況を把握することが難しく、また、コンテナのライフサイクルも短いため頻繁に稼働するノードが変更される可能性があるため、ノード単位での監視設定ができません。

また、ログファイルがPod単位のため、同じアプリケーションでもPodがダウンすると別のログファイルとして扱われるなど、どのNamespaceのどのPodのログなのかを判別することが難しいという特徴もあります。

S&Iが従来から得意としているZabbixによるシステム監視は、ホスト（ノード）単位でAgentを導入し、決まった監視ルールの適用やIPアドレスベースでの死活監視など、静的監視がメインです。ノード単位での監視設定ができないKubernetes環境にはちょっと不向きです。

そこで今回は、コストの観点も考慮しながら、Kubernetesクラスタ内部からの監視と外部からの監視、そしてログ監視の機能の3つのポイントに重点を置いて構築しました。

• ① Kubernetesクラスタ内部からの監視
• ② Kubernetesクラスタ外部からのICMP/ポート監視
• ③ ログ監視

Kubernetesクラスタ内部の状況を外部から把握することは難しいため、Kubernetesクラスタ内にオープンソースのPrometheus（プロメテウス）という監視用ソフトウェアをデプロイし、内部からKubernetesシステム、アプリケーションの監視を行います。

各ノードにPrometheusの「Node Exporter」などのコンポーネントを導入することで、Kubernetes のCPUやメモリー、ディスク使用率等のリソース情報やアプリケーションのプロセス（Pod）稼働状況を取得できます。また、Prometheusは収集したデータ（メトリクス）に異常があった場合には、「Alertmanager」というコンポーネントを経由してSlackへアラートを通知します。

Kubernetesクラスタ全体の障害や内部監視機能に問題が発生した際にも異常を検知できるように、Kubernetesクラスタ外部に監視サーバーを別途構築しました。

仮想サーバー上にDockerを導入したコンテナベースでの監視システムとなっています。外部監視にもPrometheusを導入し、「Blackbox Exporter」と呼ばれるツールを経由して、Kubernetesクラスタ内で稼働しているアプリケーションのポート監視やワーカーノードのICMP監視を行っています。

Prometheus単体では、取得した監視データの可視化に最小限の機能しか用意されていないため、高度にグラフ表示などが可能な「Grafana」と呼ばれるソフトウェアを導入しています。Grafanaの機能によりSlackに画像データ付きのアラートを通知することも可能です。

障害原因を特定する上でログを確認することは重要です。その為、外部監視サーバーに各種ログを連携し、エラーなど特定メッセージを検知した場合には通知するといった仕組みを導入しました。

今回実装したログ監視の仕様は、以下の通りです。

• 1. 各Pod のログはホストのディレクトリに保存される
• 2. fluent bitは定義されたルールに従い、ホスト上のログファイルをtailする
• 3. fluent bitはログのタグを解析し、解析結果を元に Kubernetes api-server に対しPodのメタデータを要求
• 4. Kubernetes api-server は要求を受けたログからラベルなどのメタデータを返却
• 5. fluent bit から Grafana Loki へ JSON 形式のログを Post する
• 6. Grafana から Grafana Loki に対してログクエリ(LogQL)を使用し、エラーログのみを抽出する
• 7. Grafana はエラーログの件数を監視しており、1つ以上のエラーログがあった場合、Slack へ通知

Kubernetesクラスタにおける監視の実装に非常に苦労しました。特にログ監視は、従来のシステムと比較して非常に特殊で、そのままでは各種ログの判別が難しく、ログのラベリング方法の調査に時間がかかりました。

また、監視システムを実装するにあたり、コストを可能な限り抑えたいという要件がありました。Kubernetesクラスタのログ監視では、KibanaとElasticsearchを組み合わせた構成が標準とされていますが、Elasticsearchは要求されるリソースが多く、ログ監視だけの用途としては、高コストとなってしまいます。そこで、ElasticsearchとKibanaの代わりに、Grafana Lokiを使用することで、Grafanaとの相性も良く、低リソース/低コストで動作する監視サーバーを構築することができました。