第10章 ログの収集および転送
10.1. ログの収集と転送
Red Hat OpenShift Logging Operator は、ClusterLogForwarder リソース仕様に基づいてコレクターをデプロイします。この Operator では、レガシーの Fluentd コレクターと Vector コレクターの 2 つのコレクターオプションがサポートされています。
Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。
10.1.1. ログの収集
ログコレクターは、コンテナーとノードのログを収集するために各 OpenShift Container Platform ノードに Pod をデプロイするデーモンセットです。
デフォルトでは、ログコレクターは以下のソースを使用します。
- システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。
-
すべてのコンテナーログ用の
/var/log/containers/*.log
監査ログを収集するようにログコレクターを設定すると、/var/log/audit/audit.log から取得されます。
ログコレクターはこれらのソースからログを収集し、ロギングの設定に応じて内部または外部に転送します。
10.1.1.1. ログコレクターのタイプ
Vector は、ロギングの Fluentd の代替機能として提供されるログコレクターです。
ClusterLogging カスタムリソース (CR) コレクション 仕様を変更して、クラスターが使用するロギングコレクターのタイプを設定できます。
Vector をコレクターとして設定する ClusterLogging CR の例
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance
namespace: openshift-logging
spec:
collection:
logs:
type: vector
vector: {}
# ...
10.1.1.2. ログ収集の制限
コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合は、ラベルやアノテーションなどの API サーバーからの情報は利用できない可能性があります。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡できない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。
利用可能なコンテナーランタイムは、ログメッセージのソースを特定するための最小限の情報を提供し、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、そのソースを追跡できる訳ではありません。
10.1.1.3. タイプ別のログコレクター機能
| 機能 | Fluentd | Vector |
|---|---|---|
| アプリコンテナーのログ | ✓ | ✓ |
| アプリ固有のルーティング | ✓ | ✓ |
| namespace 別のアプリ固有のルーティング | ✓ | ✓ |
| インフラコンテナーログ | ✓ | ✓ |
| インフラジャーナルログ | ✓ | ✓ |
| Kube API 監査ログ | ✓ | ✓ |
| OpenShift API 監査ログ | ✓ | ✓ |
| Open Virtual Network (OVN) 監査ログ | ✓ | ✓ |
| 機能 | Fluentd | Vector |
|---|---|---|
| Elasticsearch 証明書 | ✓ | ✓ |
| Elasticsearch ユーザー名/パスワード | ✓ | ✓ |
| Amazon Cloudwatch キー | ✓ | ✓ |
| Amazon Cloudwatch STS | ✓ | ✓ |
| Kafka 証明書 | ✓ | ✓ |
| Kafka のユーザー名/パスワード | ✓ | ✓ |
| Kafka SASL | ✓ | ✓ |
| Loki ベアラートークン | ✓ | ✓ |
| 機能 | Fluentd | Vector |
|---|---|---|
| Viaq データモデル - アプリ | ✓ | ✓ |
| Viaq データモデル - インフラ | ✓ | ✓ |
| Viaq データモデル - インフラ (ジャーナル) | ✓ | ✓ |
| Viaq データモデル - Linux 監査 | ✓ | ✓ |
| Viaq データモデル - kube-apiserver 監査 | ✓ | ✓ |
| Viaq データモデル - OpenShift API 監査 | ✓ | ✓ |
| Viaq データモデル - OVN | ✓ | ✓ |
| ログレベルの正規化 | ✓ | ✓ |
| JSON 解析 | ✓ | ✓ |
| 構造化インデックス | ✓ | ✓ |
| 複数行エラー検出 | ✓ | ✓ |
| マルチコンテナー/分割インデックス | ✓ | ✓ |
| ラベルのフラット化 | ✓ | ✓ |
| CLF 静的ラベル | ✓ | ✓ |
| 機能 | Fluentd | Vector |
|---|---|---|
| Fluentd readlinelimit | ✓ | |
| Fluentd バッファー | ✓ | |
| -chunklimitsize | ✓ | |
| - totallimitsize | ✓ | |
| - overflowaction | ✓ | |
| - flushthreadcount | ✓ | |
| - flushmode | ✓ | |
| - flushinterval | ✓ | |
| - retrywait | ✓ | |
| - retrytype | ✓ | |
| - retrymaxinterval | ✓ | |
| - retrytimeout | ✓ |
| 機能 | Fluentd | Vector |
|---|---|---|
| メトリクス | ✓ | ✓ |
| ダッシュボード | ✓ | ✓ |
| アラート | ✓ | ✓ |
| 機能 | Fluentd | Vector |
|---|---|---|
| グローバルプロキシーサポート | ✓ | ✓ |
| x86 サポート | ✓ | ✓ |
| ARM サポート | ✓ | ✓ |
| IBM Power® サポート | ✓ | ✓ |
| IBM Z® サポート | ✓ | ✓ |
| IPv6 サポート | ✓ | ✓ |
| ログイベントのバッファリング | ✓ | |
| 非接続クラスター | ✓ | ✓ |
10.1.1.4. コレクターの出力
次のコレクターの出力がサポートされています。
| 機能 | Fluentd | Vector |
|---|---|---|
| Elasticsearch v6-v8 | ✓ | ✓ |
| Fluent 転送 | ✓ | |
| Syslog RFC3164 | ✓ | ✓ (Logging 5.7+) |
| Syslog RFC5424 | ✓ | ✓ (Logging 5.7+) |
| Kafka | ✓ | ✓ |
| Amazon Cloudwatch | ✓ | ✓ |
| Amazon Cloudwatch STS | ✓ | ✓ |
| Loki | ✓ | ✓ |
| HTTP | ✓ | ✓ (Logging 5.7+) |
| Google Cloud Logging | ✓ | ✓ |
| Splunk | ✓ (Logging 5.6+) |
10.1.2. ログ転送
管理者は、収集するログ、その変換方法と転送先を指定する ClusterLogForwarder リソースを作成できます。
ClusterLogForwarder リソースは、コンテナー、インフラストラクチャー、監査ログをクラスター内外の特定のエンドポイントに転送するために使用できます。Transport Layer Security (TLS) がサポートされているため、ログを安全に送信するようにログフォワーダーを設定できます。
管理者は、どのサービスアカウントとユーザーがどの種類のログにアクセスして転送できるかを定義する RBAC アクセス許可を承認することもできます。
10.1.2.1. ログ転送の実装
レガシーの実装とマルチログフォワーダー機能という 2 つのログ転送実装を使用できます。
マルチログフォワーダー機能と併用するには、Vector コレクターのみがサポートされます。Fluentd コレクターは、レガシーの実装でのみ使用できます。
10.1.2.1.1. レガシー実装
レガシー実装では、クラスターで 1 つのログフォワーダーのみを使用できます。このモードの ClusterLogForwarder リソースは、instance という名前を付け、openshift-logging namespace に作成する必要があります。ClusterLogForwarder リソースは、openshift-logging namespace に、instance という名前の、対応する ClusterLogging リソースも必要です。
10.1.2.1.2. マルチログフォワーダー機能
マルチログフォワーダー機能は、Logging 5.8 以降で利用でき、以下の機能が提供されます。
- 管理者は、どのユーザーにログ収集の定義を許可するか、どのユーザーにどのログの収集を許可するかを制御できます。
- 必要な権限が割り当てられたユーザーは、追加のログ収集設定を指定できます。
- 非推奨の Fluentd コレクターから Vector コレクターに移行する管理者は、既存のデプロイメントとは別に新しいログフォワーダーをデプロイできます。既存および新しいログフォワーダーは、ワークロードの移行中に同時に動作します。
マルチログフォワーダーの実装では、ClusterLogForwarder リソースに対応する ClusterLogging リソースを作成する必要はありません。任意の名前を使用して、任意の namespace で複数の ClusterLogForwarder リソースを作成できますが、次の例外があります。
-
instanceという名前のClusterLogForwarderリソースは、Fluentd コレクターを使用するレガシーのワークフローに対応するログフォワーダー向けに予約されているので、openshift-loggingnamespace でこのリソースを作成できません。 -
これはコレクター用に予約されているため、
openshift-loggingnamespace にcollectorという名前のClusterLogForwarderリソースを作成することはできません。
10.1.2.2. クラスターのマルチログフォワーダー機能の有効化
マルチログフォワーダー機能を使用するには、サービスアカウントとそのサービスアカウントのクラスターロールバインディングを作成する必要があります。その後、ClusterLogForwarder リソース内のサービスアカウントを参照して、アクセス許可を制御できます。
openshift-logging namespace 以外の追加の namespace でマルチログ転送をサポートするには、すべての namespace を監視するように Red Hat OpenShift Logging Operator を更新 する必要があります。この機能は、新しい Red Hat OpenShift Logging Operator バージョン 5.8 インストールでデフォルトでサポートされています。
10.1.2.2.1. ログ収集の RBAC 権限の認可
Logging 5.8 以降では、Red Hat OpenShift Operator は collect-audit-logs、collect-application-logs、および collect-infrastructural-logs クラスターロールを提供するため、コレクターは監査ログ、アプリケーションログ、インフラストラクチャーログをそれぞれ収集できます。
必要なクラスターロールをサービスアカウントにバインドすることで、ログコレクションの RBAC パーミッションを承認できます。
前提条件
-
Red Hat OpenShift Logging Operator が
openshift-loggingnamespace にインストールされている。 - 管理者権限がある。
手順
- コレクターのサービスアカウントを作成します。認証にトークンを必要とするストレージにログを書き込む場合は、サービスアカウントにトークンを含める必要があります。
適切なクラスターロールをサービスアカウントにバインドします。
バインドコマンドの例
$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
