ざっくり理解するOpenShiftのログ管理方式

始めに

この記事ではOpenShiftにおけるアプリケーションログの保存方式について、その概要を解説します。

詳細な機能や仕様には深入りせず、ログ保存の全体像をつかむことを目的としています。
OpenShiftを使い始めたばかりで、OpenShiftでのログ保存・管理の仕組みを手早く理解したい方は、ぜひ参考にしてください。

OpenShiftでのログ保存方式

OpenShiftにおいてはログを保存する方式として、大きく以下2種類が考えられます。

1. OpenShift Loggingを利用する方式
   OpenShift Logging：OpenShiftクラスター内で実行されるアプリケーションやシステムからのログを一元的に収集、管理、可視化するためのソリューション
2. 永続ボリュームへログを出力させる方式

以下それぞれ簡単な図で説明します。

1. OpenShift Loggingを利用する方式

OpenShiftの標準的な機能であるOpenShift Loggingにてログを集中管理する方式です。

ログ記録の流れ

1. OpenShift(Kubernetes)によりコンテナの標準出力内容が各ノードのホストマシンローカルストレージへ記録
2. OpenShift Loggingが各ローカルストレージからログデータを収集
   収集にはFluentdやVectorが利用されます。
3. 外部ストレージにログを転送・保存
   ここでの外部ストレージはOpenShift Loggingの持つログストア(ElasticSearchやLoki)を指します。
   　※別途、Cloudwatch、S3、クラスタ外部のSyslogサーバなどにも転送可能です。
4. ログをOpenShift Webコンソールから可視化・検索が可能

メリット

• アプリケーション側はコンテナのログを標準出力するよう設定するだけで済みます
• ログの収集・管理をOpenShift Loggingに集約できるため、設定や運用が容易です

デメリット

• 仕組み上、ログの長期保存には適していません
  • 長期保存が必要な場合など、OpenShift Loggingを利用し外部のSyslogやFluentd、ストレージなどにログを転送することは可能です
• 大量トラフィック発生時には、OpenShift Loggingの負荷が高くなり処理能力の限界からログの取りこぼし、遅延が発生する可能性があります
  • 事前の検証・負荷試験などで必要なリソースを確認し、確保しておく必要があります

2.永続ボリュームへログを出力させる方式

仮想マシンなどと同様に、Pod(コンテナ)へ外部ストレージをマウントしそこへログを出力する方式です。

ログ記録の流れ

1. アプリケーション設定にてストレージをマウントする予定のディレクトリパスをログ出力先へ指定しておく
2. User Podに外部ストレージをマウント
3. アプリケーションがログを指定ディレクトリに書き込む
4. ログが外部ストレージに保存される

メリット

• 1つのPodに複数のコンテナがある場合でも、出力先を分けることでコンテナごとにログを分離して管理できます
  • 1つのPodに複数のストレージをマウントすることも可能です
• ストレージ装置側の処理性能に依存しますが、コンテナ(アプリケーション)から直接ストレージへ書き込みを行うため、ログの取りこぼしの可能性は比較的低いと言えます

デメリット

• Podごとにストレージを用意する必要があります
• アプリケーション側で、ログファイルの出力先パスを指定する設定が別途必要になります
• その他、場合によってはログのマージや転送、可視化のためのソフトウェアの用意などOpenShift Loggingを利用する方式と比較すると設定や運用には手間がかかります

【参考】PV/PVCについて

OpenShift上のコンテナに外部ストレージをマウントするには、PV、PVCを利用する必要があります。
これらについても参考として簡単に説明します。

まず、PV（PersistentVolume）は、ストレージそのものを抽象化したリソースです。例えば、NAS装置のアドレスや利用する容量、ディレクトリといった情報が定義されています。

一方、PVC（PersistentVolumeClaim）は、コンテナが「これくらいの容量のストレージを使いたい」といった要求（Claim）を定義するリソースです。

PVCの要求に合致するPVが存在すると、両者は自動的にバインド（紐付け）されます。
そして、バインドされたPVCをPodのディレクトリへマウントすることで、Pod内のコンテナから外部ストレージが利用できるようになります。

【参考】永続ボリューム方式の課題と解決策

PVC/PVで確保した外部ストレージをPodにマウントし、アプリケーションの設定でログの出力先をそのマウントパスに指定することで、ログを直接外部ストレージへ書き込みますが、本方式では以下のような課題が存在します。

課題

この方式ではアプリケーションがログを出力するところまでしか設定を行いません。

そのため、ログのローテーション（古いログの削除や圧縮）や、複数ファイルのマージといった処理が必要な場合は、別途仕組みを検討する必要があります。

ここで注意したいのが、Pod内部でlogrotateを実行する方法です。
これは以下の理由により、OpenShift（Kubernetes）環境では一般的に推奨されません。

• Podが再起動すると、logrotateが自身の実行状態を記録するステータスファイルも一緒にリセットされてしまう
• その結果、ローテーションが意図した通りに行われない可能性がある

解決策の例

この課題を解決するには、Podの外部からローテーションを制御するアプローチが考えられます。

• 外部サーバから実行
  • 管理用サーバなどからlogrotateやCronジョブを使い、マウント先のログファイルを直接処理する
• ocコマンドで実行
  • oc execコマンドを使い、外部から定期的にPodで実行しているアプリケーションに対応したログ操作コマンドを実行させる
    • ocコマンド：OpenShiftを操作するための専用コマンドラインツール

【参考】サイドカーを利用した永続ボリュームの書き込み

別パターン（1. OpenShift Loggingを利用する方式との合わせ技）として、サイドカーコンテナを利用した永続ボリュームへの書き込みを行うことも可能です。

• アプリケーションコンテナではログを標準出力へ出力します
  • 各コンテナの標準出力は各ノードのホストマシンローカルストレージへ記録されます
  • OpenShift Loggingがログを収集することができます
• サイドカーコンテナへ外部ストレージをマウントします
  • サイドカーコンテナはアプリケーションコンテナの標準出力を監視し、マウントした外部ストレージへ書き込みを行います

全体的な設定の手間はかかりますが、アプリケーションコンテナとログ出力用コンテナの管理を分けることができる、OpenShift Loggingの恩恵も受けられる(組み合わせてログを管理できる)などのメリットがあります。

まとめ

この記事では、OpenShiftのログ保存方式について簡単に解説しました。

最後に、紹介した2つの方式のメリデメをまとめて記載します。

方式	メリット	デメリット
OpenShift Loggingを利用する方式	アプリケーション側はコンテナのログを標準出力するよう設定するだけで良い。 収集・管理をOpenShift Loggingに集約できるため、設定や運用が容易。	仕組み上、ログの長期保存には適していない。 ※長期保存が必要な場合など、OpenShift Loggingを利用し外部のSyslogやFluentd、ストレージなどにログを転送することは可能。 大量トラフィック発生時には、OpenShift Loggingの負荷が高くなり処理能力の限界からログの取りこぼし、遅延が発生する可能性がある。 ※事前の検証・負荷試験などで必要なリソースを確認する必要有がある。
永続ボリュームへログを出力させる方式	1つのPodに複数のコンテナがある場合でも、出力先を分けることでコンテナごとにログを分離して管理可能。 コンテナ(アプリケーション)から直接ストレージへ書き込みを行うため、ログの取りこぼしの可能性は比較的低い。(ストレージ装置の性能にも依存)	Podごとにストレージを用意する必要がある。 アプリケーション側で、ログファイルの出力先パスを指定する設定が別途必要。 場合によってはログのマージや転送、可視化のためのソフトウェアの用意など設定や運用には手間がかかる。

説明した2つの方式の内、どちらが良いというわけではなく
ログの重要度や量、保存期間といった要件に合わせて、最適な方式を選択することが大切です。

また、本記事で紹介した方式をベースにサイドカーやFluentdなどのロギングエージェントを活用することでさらに柔軟なログ収集の仕組みを構築することも可能です。

以上、ざっくりとしたOpenShiftのログ管理方式の解説でした