第1章 クラスターロギングについて
クラスター管理者は、クラスターロギングをデプロイし、ノードシステムの監査ログ、アプリケーションコンテナーログ、およびインフラストラクチャーログなどの OpenShift Container Platform クラスターからのすべてのログを集計できます。クラスターロギングはクラスター全体でこれらのログを集計し、それらをデフォルトのログストアに保存します。Kibana Web コンソールを使用して、ログデータを可視化 できます。
クラスターロギングは以下のタイプのログを集計します。
-
application: クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。 -
infrastructure: ジャーナルログなどの、クラスターで実行されるインフラストラクチャーコンポーネントおよび OpenShift Container Platform ノードで生成されるログ。インフラストラクチャーコンポーネントは、openshift*、kube*、またはdefaultプロジェクトで実行される Pod です。 -
audit: ノード監査システム (auditd) で生成されるログ (/var/log/audit/audit.log ファイルに保存される)、および Kubernetes apiserver および OpenShift apiserver の監査ログ。
内部 OpenShift Container Platform Elasticsearch ログストアは監査ログのセキュアなストレージを提供しないため、デフォルトで監査ログは内部 Elasticsearch インスタンスに保存されません。監査ログを内部ログストアに送信する必要がある場合 (Kibana で監査ログを表示するなど)、Forward audit logs to the log store で説明されているようにログ転送 API を使用する必要があります。
1.1. クラスターロギングのデプロイについて
OpenShift Container Platform クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI コマンドを使用してクラスターロギングをデプロイし、Elasticsearch Operator および Cluster Logging Operator をインストールできます。Operator がインストールされている場合、 ClusterLogging カスタムリソース (Custom Resource、CR) を作成してクラスターロギング Pod およびクラスターロギングのサポートに必要な他のリソースをスケジュールします。Operator はクラスターロギングのデプロイ、アップグレード、および維持を行います。
ClusterLogging CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なクラスターロギング環境を定義します。Cluster Logging Operator は Cluster Logging CR を監視し、ロギングデプロイメントを適宜調整します。
管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。
詳細は、ログコレクターの設定 について参照してください。
1.1.1. クラスターロギングのコンポーネントについて
クラスターロギングコンポーネントには、すべてのノードおよびコンテナーログを収集し、それらをログストアに書き込む OpenShift Container Platform クラスターの各ノードにデプロイされるコレクターが含まれます。一元化された Web UI を使用し、集計されたデータを使用して高度な可視化 (visualization) およびダッシュボードを作成できます。
クラスターロギングの主要コンポーネントは以下の通りです。
- collection: これは、クラスターからログを収集し、それらをフォーマットし、ログストアに転送するコンポーネントです。現在の実装は Fluentd です。
- log store: これはログが保存される場所です。デフォルトの実装は Elasticsearch です。デフォルトの Elasticsearch ログストアを使用するか、またはログを外部ログストアに転送することができます。デフォルトのログストアは、短期の保存について最適化され、テストされています。
- visualization: これは、ログ、グラフ、チャートなどを表示するために使用される UI コンポーネントです。現在の実装は Kibana です。
本書では、特筆されない限り、log store と Elasticsearch、visualization と Kibana、collection と Fluentd を区別せずに使用する場合があります。
1.1.2. ロギングコレクターについて
OpenShift Container Platform は Fluentd を使用してコンテナーおよびノードのログを収集します。
デフォルトでは、ログコレクターは以下のソースを使用します。
- すべてのシステムログ用の journald
-
すべてのコンテナーログ用の
/var/log/containers/*.log
ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットとしてデプロイされます。システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。アプリケーションログは CRI-O コンテナーエンジンによって生成されます。Fluentd はこれらのソースからログを収集し、OpenShift Container Platform で設定したように内部または外部に転送します。
コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合、ラベルやアノテーションなどの API サーバーからの情報は利用できない可能性があります。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡することができない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。
利用可能なコンテナーランタイムは、ログメッセージのソースを特定するための最小限の情報を提供し、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、そのソースを追跡できる訳ではありません。
詳細は、ログコレクターの設定 について参照してください。
1.1.3. ログストアについて
デフォルトで、OpenShift Container Platform は Elasticsearch (ES) を使用してログデータを保存します。オプションで、ログ転送機能を使用して、Fluentd プロトコル、syslog プロトコル、または OpenShift Container Platform ログ転送 API を使用してログを外部ログストアに転送できます。
クラスターロギング Elasticsearch インスタンスは、短期 (約 7 日間) の保存について最適化され、テストされています。長期間ログを保持する必要がある場合は、データをサードパーティーのストレージシステムに移動することが推奨されます。
Elasticsearch は Fluentd からのログデータをデータストアまたは インデックス に編成し、それぞれのインデックスを シャード と呼ばれる複数の部分に分割します。これは、Elasticsearch クラスターの Elasticsearch ノードセット全体に分散されます。Elasticsearch を、レプリカ と呼ばれるシャードのコピーを作成するように設定できます。Elasticsearch はこれを Elasticsearch ノード全体に分散します。ClusterLogging カスタムリソース (CR) により、データの冗長性および耐障害性を確保するためにシャードを複製する方法を指定できます。また、ClusterLogging CR の保持ポリシーを使用して各種のログが保持される期間を指定することもできます。
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
Cluster Logging Operator および Elasticsearch Operator は、各 Elasticsearch ノードが独自のストレージボリュームを含む一意のデプロイメントを使用してデプロイされるようにします。ClusterLogging カスタムリソース (CR) を使用して Elasticsearch ノードの数を適宜増やすことができます。ストレージの設定に関する考慮事項については、Elasticsearch ドキュメント を参照してください。
可用性の高い Elasticsearch 環境には 3 つ以上の Elasticsearch ノードが必要で、それぞれが別のホストに置かれる必要があります。
Elasticsearch インデックスに適用されているロールベースアクセス制御 (RBAC) は、開発者のログの制御アクセスを可能にします。管理者はすべてのログに、開発者は各自のプロジェクトのログにのみアクセスできます。
詳細は、ログストアの設定 について参照してください。
1.1.4. ロギングの可視化について
OpenShift Container Platform は Kibana を使用して、Fluentd によって収集され、Elasticsearch によってインデックス化されるログデータを表示します。
Kibana は、ヒストグラム、線グラフ、円グラフその他の可視化機能を使用して Elasticsearch データをクエリーし、検出し、可視化するためのブラウザーベースのコンソールインターフェイスです。
詳細は、ログビジュアライザーの設定 について参照してください。
1.1.5. イベントのルーティングについて
イベントルーターは、クラスターロギングで収集できるように OpenShift Container Platform イベントを監視する Pod です。イベントルーターはすべてのプロジェクトからイベントを収集し、それらを STDOUT に書き込みます。Fluentd はそれらのイベントを収集し、それらを OpenShift Container Platform Elasticsearch インスタンスに転送します。Elasticsearch はイベントを infra インデックスにインデックス化します。
イベントルーターは手動でデプロイする必要があります。
詳細は、 Kubernetes イベントの収集および保存 について参照してください。
1.1.6. ログ転送
デフォルトで、OpenShift Container Platform クラスターロギングは ClusterLogging カスタムリソース (CR) に定義されるデフォルトの内部 Elasticsearch ログストアにログを送信します。ログを他のログアグリゲーターに転送する必要がある場合、ログ転送機能を使用してログをクラスター内外の特定のエンドポイントに送信することができます。
詳細は、ログのサードパーティーシステムへの転送 について参照してください。
