ロギング

OpenShift Container Platform 4.12

OpenShift Logging のインストール、使用法、およびリリースノート

Red Hat OpenShift Documentation Team

概要

本書では、OpenShift Logging のインストール、設定および使用方法について説明します。OpenShift Logging は、各種の OpenShift Container Platform サービスについてのログを集計します。

第1章 ロギングのリリースノート

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

注記

stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

1.1. Logging 5.7.1

このリリースには、OpenShift Logging Bug Fix Release 5.7.1 が含まれています。

1.1.1. バグ修正

  • この更新が行われる前は、Cluster Logging Operator Pod ログ内に多数のノイズの多いメッセージが存在するため、ログの可読性が低下し、重要なシステムイベントを識別することが困難になりました。この更新により、Cluster Logging Operator Pod ログ内のノイズの多いメッセージが大幅に削減されることで、この問題が解決されました。(LOG-3482)
  • この更新より前は、カスタムリソースで別の値が使用されている場合でも、API サーバーは CollectorSpec.Type フィールドの値を Vector にリセットしていました。この更新では、CollectorSpec.Type フィールドのデフォルトが削除され、以前の動作が復元されます。(LOG-4086)
  • この更新が行われるまでは、OpenShift Container Platform Web コンソールでログのヒストグラムをクリックしてドラッグしても時間範囲を選択できませんでした。今回の更新により、クリックとドラッグを使用して時間範囲を正常に選択できるようになりました。(LOG-4501)
  • この更新前は、OpenShift Container Platform Web コンソールで Show Resources リンクをクリックしても何の効果もありませんでした。この更新では、ログエントリーごとにリソースの表示を切り替えるリソースの表示リンクの機能を修正することで、この問題が解決されました。(LOG-3218)

1.1.2. CVE

1.2. Logging 5.7.0

このリリースには、OpenShift Logging Bug Fix Release 5.7.0 が含まれています。

1.2.1. 機能拡張

今回の更新により、ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようになりました。

ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、ClusterLogForwarder カスタムリソース (CR) に、値が true の detectMultilineErrors フィールドが含まれていることを確認します。

1.2.2. 既知の問題

なし。

1.2.3. バグ修正

  • 今回の更新以前は、LokiStack の Gateway コンポーネントの nodeSelector 属性は、ノードのスケジューリングに影響を与えませんでした。今回の更新により、nodeSelector 属性が想定どおりに機能するようになりました。(LOG-3713)

1.2.4. CVE

1.3. Logging 5.6.6

このリリースには、OpenShift Logging Bug Fix Release 5.6.6 が含まれています。

1.3.1. バグ修正

  • この更新が行われるまでは、ペイロード内のキーに一致する Kafka 出力トピックに書き込むように ClusterLogForwarder カスタムリソースを設定すると、エラーによりメッセージのドロップが発生していました。今回の更新では、Fluentd のバッファー名の前にアンダースコアを付けることで問題が解決しました。(LOG-3458)
  • この更新が行われるまでは、inode が再利用され、同じ inode を持つ複数のエントリーが存在する場合に、Fluentd でウォッチの早期終了が発生していました。この更新により、Fluentd 位置ファイル内のウォッチが早期に終了する問題が解決しました。(LOG-3629)
  • この更新が行われるまでは、Fluentd による JavaScript クライアントの複数行例外の検出に失敗し、結果として例外が複数行として出力されていました。今回の更新により、例外が 1 行で出力されるようになり、問題が解決されました。(LOG-3761)
  • この更新が行われるまでは、Red Hat Openshift Logging Operator バージョン 4.6 からバージョン 5.6 への直接アップグレードが許可されていたため、機能上の問題が発生していました。この更新により、アップグレードは 2 つのバージョン以内である必要があり、問題が解決されました。(LOG-3837)
  • この更新が行われるまでは、Splunk または Google Logging 出力のメトリックは表示されませんでした。この更新では、HTTP エンドポイントのメトリックを送信することで問題が解決されました。(LOG-3932)
  • この更新が行われるまでは、ClusterLogForwarder カスタムリソースが削除されても、コレクター Pod は実行されたままでした。この更新により、ログ転送が有効になっていない場合、コレクター Pod は実行されなくなります。(LOG-4030)
  • この更新が行われるまでは、OpenShift Container Platform Web コンソールでログのヒストグラムをクリックしてドラッグしても時間範囲を選択できませんでした。今回の更新により、クリックとドラッグを使用して時間範囲を正常に選択できるようになりました。(LOG-4101)
  • この更新が行われるまでは、監視ファイルの Fluentd ハッシュ値はログファイルへのパスを使用して生成されていたため、ログローテーション時に一意ではないハッシュが生成されました。今回の更新により、監視ファイルのハッシュ値が inode 番号で作成されるようになり、問題が解決されました。(LOG-3633)
  • この更新前は、OpenShift Container Platform Web コンソールで Show Resources リンクをクリックしても何の効果もありませんでした。この更新では、ログエントリーごとにリソースの表示を切り替える リソースの表示 リンクの機能を修正することで、この問題が解決されました。(LOG-4118)

1.3.2. CVE

1.4. Logging 5.6.5

このリリースには、OpenShift Logging Bug Fix Release 5.6.5 が含まれています。

1.4.1. バグ修正

  • この更新前は、テンプレート定義により Elasticsearch が一部のラベルと namespace_label のインデックスを作成できず、データの取り込みで問題が発生していました。この更新では、ラベル内のドットとスラッシュが修正により置き換えられ、適切な取り込みが保証され、問題が効果的に解決されます。(LOG-3419)
  • この更新より前は、OpenShift Web コンソールのログページが LokiStack への接続に失敗した場合、一般的なエラーメッセージが表示され、追加のコンテキストやトラブルシューティングの提案は提供されませんでした。この更新により、エラーメッセージが強化され、より具体的な詳細とトラブルシューティングの推奨事項が含まれるようになりました。(LOG-3750)
  • この更新より前は、時間範囲形式が検証されていなかったため、カスタム日付範囲を選択するとエラーが発生していました。この更新により、時間形式が検証されるようになり、ユーザーが有効な範囲を選択できるようになりました。無効な時間範囲形式が選択された場合、ユーザーにエラーメッセージが表示されます。(LOG-3583)
  • この更新前は、Loki でログを検索する場合、式の長さが 5120 文字を超えていない場合でも、多くの場合、クエリーは失敗していました。この更新により、クエリー承認ラベルマッチャーが最適化され、問題が解決されました。(LOG-3480)
  • この更新が行われる前は、Loki Operator は、プライベート IP のメンバーリストを使用する場合に、すべてのコンポーネントを見つけるのに十分なメンバーリスト設定を生成できませんでした。今回の更新により、生成された設定にアドバタイズされたポートが確実に含まれるようになり、すべてのコンポーネントを正常に検索できるようになりました。(LOG-4008)

1.4.2. CVE

1.5. Logging 5.6.4

このリリースには、OpenShift Logging Bug Fix Release 5.6.4 が含まれています。

1.5.1. バグ修正

  • この更新の前は、LokiStack がログストアとしてデプロイされたときに、Loki Pod によって生成されたログが収集され、LokiStack に送信されていました。今回の更新により、Loki によって生成されたログは収集から除外され、保存されなくなります。(LOG-3280)
  • この更新の前は、OpenShift Web コンソールのログページのクエリーエディターが空の場合は、ドロップダウンメニューに値が入力されませんでした。今回の更新により、空のクエリーを実行しようとすると、エラーメッセージが表示され、ドロップダウンメニューが期待どおりに入力されるようになりました。(LOG-3454)
  • この更新の前は、tls.insecureSkipVerify オプションが true に設定されている場合は、Cluster Logging Operator が誤った設定を生成していました。その結果、Operator は証明書の検証をスキップしようとすると、データを Elasticsearch に送信できませんでした。今回の更新により、tls.insecureSkipVerify が 有効になっている場合でも、Cluster Logging Operator は正しい TLS 設定を生成します。その結果、証明書の検証をスキップしようとしても、データを Elasticsearch に正常に送信できます。(LOG-3475)
  • この更新の前は、構造化された解析が有効になっていて、メッセージが複数の宛先に転送された場合、それらはディープコピーされませんでした。これにより、構造化されたメッセージを含む一部の受信ログが生成されましたが、その他のログは生成されませんでした。今回の更新により、JSON 解析の前にメッセージをディープコピーするように設定生成が変更されました。その結果、複数の宛先に転送された場合でも、すべての受信メッセージに構造化メッセージが含まれるようになりました。(LOG-3640)
  • この更新の前は、collection フィールドに {} が含まれていると、Operator がクラッシュする可能性がありました。今回の更新により、Operator はこの値を無視するようになり、オペレータは中断することなくスムーズに実行し続けることができます。(LOG-3733)
  • この更新の前は、LokiStack のゲートウェイコンポーネントの nodeSelector 属性は効果がありませんでした。今回の更新により、nodeSelector 属性が期待どおりに機能するようになりました。(LOG-3783)
  • この更新の前は、静的な LokiStack メンバーリストの設定は、プライベート IP ネットワークのみに依存していました。その結果、OpenShift Container Platform クラスター Pod ネットワークがパブリック IP 範囲で設定されている場合、LokiStack Pod がクラッシュループします。今回の更新により、LokiStack 管理者は、メンバーリストの設定に Pod ネットワークを使用するオプションを利用できるようになりました。これにより、問題が解決され、OpenShift Container Platform クラスター Pod ネットワークがパブリック IP 範囲で設定されている場合に、LokiStack Pod がクラッシュループ状態になるのを防ぐことができます。(LOG-3814)
  • この更新の前は、tls.insecureSkipVerify フィールドが true に設定されている場合、Cluster Logging Operator は間違った設定を生成していました。その結果、証明書の検証をスキップしようとすると、Operator は Elasticsearch にデータを送信できませんでした。今回の更新により、tls.insecureSkipVerify が有効になっている場合でも、Operator は正しい TLS 設定を生成します。その結果、証明書の検証をスキップしようとしても、データを Elasticsearch に正常に送信できます。(LOG-3838)
  • この更新の前に、Elasticsearch Operator を使用せずに Cluster Logging Operator (CLO) がインストールされた場合、CLO Pod は Elasticsearch の削除に関連するエラーメッセージを継続的に表示していました。今回の更新により、CLO はエラーメッセージを表示する前に追加のチェックを実行するようになりました。その結果、Elasticsearch Operator が存在しない場合は、Elasticsearch の削除に関連するエラーメッセージが表示されなくなりました。(LOG-3763)

1.5.2. CVE

1.6. Logging 5.6.3

このリリースには、OpenShift Logging Bug Fix Release 5.6.3 が含まれています。

1.6.1. バグ修正

  • 今回の更新の前は、Operator はゲートウェイテナントのシークレット情報を config map に保存していました。今回の更新により、Operator はこの情報をシークレットに保存します。(LOG-3717)
  • 今回の更新の前は、Fluentd コレクターは /var/log/auth-server/audit.log に保存されている OAuth ログインイベントをキャプチャーしませんでした。今回の更新により、Fluentd は、これらの OAuth ログインイベントをキャプチャーし、問題を解決しました。(LOG-3729)

1.6.2. CVE

1.7. Logging 5.6.2

本リリースには、OpenShift Logging バグ修正リリース 5.6.2 が含まれます。

1.7.1. バグ修正

  • この更新の前は、コレクターは systemd ログの優先度に基づいて level フィールドを正しく設定しませんでした。今回の更新により、level フィールドが正しく設定されるようになりました。(LOG-3429)
  • 今回の更新以前は、Operator は OpenShift Container Platform 4.12 以降で非互換性の警告を誤って生成していました。今回の更新により、Operator の OpenShift Container Platform の最大バージョン値が修正され、問題が解決されました。(LOG-3584)
  • 今回の更新以前は、default の出力値で ClusterLogForwarder カスタムリソース (CR) を作成し、エラーを生成しませんでした。今回の更新により、この値が適切に生成されるというエラーの警告が表示されるようになりました。(LOG-3437)
  • この更新の前は、ClusterLogForwarder カスタムリソース (CR) に 1 つの出力が default として設定された複数のパイプラインがある場合、コレクター Pod は再起動していました。今回の更新で、出力検証のロジックが修正され、問題が解決されました。(LOG-3559)
  • この更新の前は、コレクター Pod は作成後に再起動されていました。今回の更新により、デプロイされたコレクターが自動的に再起動しなくなりました。(LOG-3608)
  • 今回の更新以前は、パッチリリースがカタログから以前のバージョンの Operator を削除していました。これにより、古いバージョンをインストールすることができませんでした。今回の更新により、バンドル設定が変更され、同じマイナーバージョンの以前のリリースがカタログに留まるようになりました。(LOG-3635)

1.7.2. CVE

1.8. Logging 5.6.1

本リリースには、OpenShift Logging バグ修正リリース 5.6.1 が含まれます。

1.8.1. バグ修正

  • この更新の前は、保持が有効な場合、コンパクターは、クエリーアとの通信による TLS 証明書エラーを報告していました。今回の更新により、コンパクターとクエリーアが HTTP 経由で誤って通信することがなくなりました。(LOG-3494)
  • この更新の前は、Loki Operator は LokiStack CR のステータスの設定を再試行しないため、ステータス情報が古くなっていました。今回の更新により、Operator は競合時にステータス情報の更新を再試行するようになりました。(LOG-3496)
  • この更新の前は、kube-apiserver-operator Operator が Webhook の有効性を確認したときに、Loki Operator Webhook サーバーが TLS エラーを引き起こしていました。今回の更新により、Loki Operator Webhook PKI は Operator Lifecycle Manager (OLM) によって管理されるようになり、問題が解決されました。(LOG-3510)
  • この更新の前は、ブール式と組み合わせてラベルフィルターを使用した場合、LokiStack ゲートウェイラベルエンフォーサーが有効な LogQL クエリーの解析エラーを生成していました。今回の更新により、LokiStack LogQL の実装がブール式を使用したラベルフィルターをサポートするようになり、問題が解決されました。(LOG-3441)、(LOG-3397)
  • この更新の前は、複数のラベルキーに同じ接頭辞があり、一部のキーにドットが含まれていると、Elasticsearch に書き込まれたレコードで障害が発生していました。今回の更新により、ラベルキーのドットがアンダースコアに置き換えられ、問題が解決されました。(LOG-3463)
  • この更新の前は、OpenShift Container Platform コンソールと logging-view-plugin の間に互換性がないため、Red Hat OpenShift Logging Operator は OpenShift Container Platform 4.10 クラスターで使用できませんでした。今回の更新により、プラグインは OpenShift Container Platform 4.10 管理コンソールと適切に統合されるようになりました。(LOG-3447)
  • この更新の前は、ClusterLogForwarder カスタムリソースの調整で、デフォルトログストアを参照するパイプラインの低下ステータスが誤って報告されていました。今回の更新により、パイプラインが適切に検証されるようになりました (LOG-3477)。

1.8.2. CVE

1.9. Logging 5.6

このリリースには、OpenShift Logging Release 5.6 が含まれています。

1.9.1. 非推奨の通知

Logging 5.6 では、Fluentd が非推奨となり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Fluentd の代わりに、Vector を使用できます。

1.9.2. 機能拡張

  • 今回の更新により、Logging は OpenShift Container Platform のクラスター全体の暗号化ポリシーに準拠します。(LOG-895)
  • 今回の更新により、LokiStack カスタムリソースを使用して、テナントごと、ストリームごと、およびグローバルポリシーの保持ポリシーを優先度順に宣言できるようになります。(LOG-2695)
  • 今回の更新により、Splunk がログ転送の出力オプションとして利用できるようになります。(LOG-2913)
  • 今回の更新により、デフォルトコレクターが Fluentd から Vector になります。(LOG-2222)
  • 今回の更新により、Developer ロールは、OpenShift Container Platform 4.11 以降を実行しているクラスターの Log Console Plugin 内で割り当てられているプロジェクトごとのワークロードログにアクセスできます。(LOG-3388)
  • 今回の更新により、任意のソースからのログに、Operator がデプロイされているクラスターの一意識別子であるフィールド openshift.cluster_id が含まれるようになります。clusterID の値は、以下のコマンドで表示できます。(LOG-2715) 
$ oc get clusterversion/version -o jsonpath='{.spec.clusterID}{"\n"}'

1.9.3. 既知の問題

  • この更新の前は、複数のラベルキーに同じ接頭辞があり、一部のキーに . が含まれていると、Elasticsearch がログを拒否することがありました。これは、ラベルキーに含まれる . を _ に置き換えることで、Elasticsearch の制限を修正します。この問題の回避策として、エラーの原因となっているラベルを削除するか、namespace をラベルに追加します。(LOG-3463)

1.9.4. バグ修正

  • 今回の更新の前は、Kibana カスタムリソースを削除した場合、OpenShift Container Platform Web コンソールは引き続き Kibana へのリンクを表示していました。今回の更新で、Kibana カスタムリソースを削除すると、そのリンクも削除されます。(LOG-2993)
  • この更新の前は、ユーザーはアクセス権を持つ namespace のアプリケーションログを表示できませんでした。今回の更新により、Loki Operator はクラスターロールとクラスターロールバインディングを自動的に作成し、ユーザーがアプリケーションログを読み取れるようにします。(LOG-3072)
  • この更新の前に、LokiStack をデフォルトのログストレージとして使用する場合、Operator は ClusterLogForwarder カスタムリソースで定義されたカスタム出力を削除しました。今回の更新により、Operator は ClusterLogForwarder カスタムリソースの処理時にカスタム出力をデフォルト出力とマージします。(LOG-3090)
  • この更新の前に、CA キーは CA を Loki にマウントするためのボリューム名として使用されていたため、CA キーに非準拠の文字 (ドットなど) が含まれているとエラー状態が発生していました。今回の更新により、ボリューム名が内部文字列に標準化され、問題が解決されました。(LOG-3331)
  • この更新の前は、LokiStack カスタムリソース定義内で設定されたデフォルト値が原因で、1 の ReplicationFactor なしで LokiStack インスタンスを作成できませんでした。今回の更新により、Operator は使用されるサイズの実際の値を設定するようになります。(LOG-3296)
  • この更新の前は、Vector は、JSON 解析が有効になっている場合に、structuredTypeKey または structuredTypeName の値も定義せずにメッセージフィールドを解析していました。今回の更新により、構造化ログを Elasticsearch に書き込むときに、structuredTypeKey または structuredTypeName のいずれかに値が必要になりました。(LOG-3195)
  • この更新の前は、Elasticsearch Operator のシークレット作成コンポーネントが内部シークレットを常に変更していました。今回の更新により、既存のシークレットが適切に処理されるようになりました。(LOG-3161)
  • この更新の前は、Elasticsearch または Kibana デプロイメントのステータスが変更されている間に、Operator がコレクターデーモンセットの削除と再作成のループに入る可能性がありました。今回の更新では、Operator のステータス処理が修正され、問題が解決されました。(LOG-3157)
  • この更新の前は、Kibana の OAuth cookie の有効期限は 24h に固定されていたため、accessTokenInactivityTimeout フィールドが 24h 未満の値に設定されていると、Kibana で 401 エラーが発生していました。今回の更新により、Kibana の OAuth cookie の有効期限が accessTokenInactivityTimeout に同期され、デフォルト値は 24h になります。(LOG-3129)
  • この更新の前は、リソースを調整するための Operator の一般的なパターンとして、取得または更新を試みる前に作成を試みていました。そのため、作成後に一定の HTTP 409 レスポンスが発生していました。今回の更新により、Operator は最初にオブジェクトの取得を試み、オブジェクトが欠落しているか指定されていない場合にのみ作成または更新するようになります。(LOG-2919)
  • この更新の前は、Fluentd の .level フィールドと .structure.level フィールドに異なる値が含まれることがありました。今回の更新により、各フィールドの値が同じになります。(LOG-2819)
  • この更新の前は、Operator は信頼された CA バンドルの作成を待たず、バンドルが更新された後に 2 回目のコレクターデプロイメントを実行していました。今回の更新により、Operator は、コレクターデプロイメントを続行する前に、バンドルが読み込まれたかどうかを確認するために少し待機するようになります。(LOG-2789)
  • この更新の前は、メトリクスを確認するときに Telemetry ログ情報が 2 回表示されていました。今回の更新により、Telemetry ログ情報が想定どおりに表示されます。(LOG-2315)
  • この更新の前は、JSON 解析の追加を有効にした後、Fluentd Pod ログに警告メッセージが含まれていました。今回の更新でにより、その警告メッセージは表示されなくなりました。(LOG-1806)
  • この更新の前は、キャッシュをビルドするために書き込み権限を持つフォルダーを oc が必要とするため、must-gather スクリプトは完了しませんでした。今回の更新により、oc はフォルダーへの書き込み権限を持ち、must-gather スクリプトが正常に完了するようになります。(LOG-3446)
  • この更新の前は、ログコレクター SCC がクラスター上の他の SCC に取って代わられ、コレクターが使用できなくなる可能性がありました。今回の更新により、ログコレクター SCC の優先度が設定され、他の SCC よりも優先されるようになりました。(LOG-3235)
  • この更新の前は、Vector に sequence フィールドはなく、ナノ秒単位の精度の欠落に対処する方法として fluentd に追加されていました。今回の更新により、openshift.sequence フィールドがイベントログに追加されました。(LOG-3106)

1.9.5. CVE

1.10. Logging 5.5.11

このリリースには、OpenShift Logging Bug Fix Release 5.5.11 が含まれています。

1.10.1. バグ修正

  • この更新が行われるまでは、OpenShift Container Platform Web コンソールでログのヒストグラムをクリックしてドラッグしても時間範囲を選択できませんでした。今回の更新により、クリックとドラッグを使用して時間範囲を正常に選択できるようになりました。(LOG-4102)
  • この更新前は、OpenShift Container Platform Web コンソールで Show Resources リンクをクリックしても何の効果もありませんでした。この更新では、ログエントリーごとにリソースの表示を切り替える リソースの表示 リンクの機能を修正することで、この問題が解決されました。(LOG-4117)

1.10.2. CVE

1.11. Logging 5.5.10

このリリースには、OpenShift Logging Bug Fix Release 5.5.10 が含まれています。

1.11.1. バグ修正

  • 今回の更新以前は、OpenShift Web コンソールのロギングビュープラグインは、LokiStack に到達できなかった場合にのみエラーテキストを表示していました。この更新により、プラグインでは適切なエラーメッセージと、到達できない LokiStack の詳しい修正方法が表示されるようになりました。(LOG-2874)

1.11.2. CVE

1.12. Logging 5.5.9

このリリースには、OpenShift Logging Bug Fix Release 5.5.9 が含まれています。

1.12.1. バグ修正

  • この更新の前は、Fluentd コレクターの問題により、/var/log/auth-server/audit.log に保存されている OAuth ログインイベントがキャプチャーされませんでした。これにより、OAuth サービスからのログインイベントの収集が不完全になりました。今回の更新により、Fluentd コレクターは、予想どおり、/var/log/auth-server/audit.log に保存されているものを含め、OAuth サービスからすべてのログインイベントをキャプチャーすることで、この問題を解決するようになりました。(LOG-3730)
  • この更新の前は、構造化された解析が有効になっていて、メッセージが複数の宛先に転送された場合、それらはディープコピーされませんでした。これにより、構造化されたメッセージを含む一部の受信ログが生成されましたが、その他のログは生成されませんでした。今回の更新により、JSON 解析の前にメッセージをディープコピーするように設定生成が変更されました。その結果、複数の宛先に転送された場合でも、すべての受信ログに構造化メッセージが含まれるようになりました。(LOG-3767)

1.12.2. CVE

1.13. Logging 5.5.8

このリリースには、OpenShift Logging Bug Fix Release 5.5.8 が含まれています。

1.13.1. バグ修正

  • 今回の更新の前は、コレクターが level フィールドを設定する方法にエラーがあったため、priority フィールドが systemd ログから欠落していました。今回の更新により、これらのフィールドが正しく設定され、問題が解決されました。(LOG-3630)

1.13.2. CVE

1.14. Logging 5.5.7

このリリースには、OpenShift Logging バグ修正リリース 5.5.7 が含まれます。

1.14.1. バグ修正

  • この更新の前は、ブール式と組み合わせてラベルフィルターを使用した場合、LokiStack ゲートウェイラベルエンフォーサーが有効な LogQL クエリーの解析エラーを生成していました。今回の更新により、LokiStack LogQL の実装がブール式を使用したラベルフィルターをサポートするようになり、問題が解決されました。(LOG-3534)
  • この更新の前は、ClusterLogForwarder カスタムリソース (CR) が syslog 出力の TLS 認証情報を Fluentd に渡さなかったため、転送中にエラーが発生していました。今回の更新により、認証情報が Fluentd に正しく渡されるようになり、問題が解決されました。(LOG-3533)

1.14.2. CVE

CVE-2021-46848CVE-2022-3821CVE-2022-35737CVE-2022-42010CVE-2022-42011CVE-2022-42012CVE-2022-42898CVE-2022-43680

1.15. Logging 5.5.6

このリリースには、OpenShift Logging バグ修正リリース 5.5.6 が含まれます。

1.15.1. バグ修正

  • この更新の前は、Pod セキュリティーアドミッションコントローラーがラベル podSecurityLabelSync = true を openshift-logging namespace に追加していました。これにより、指定のセキュリティーラベルが上書きされ、その結果、コレクター Pod が起動しなくなりました。今回の更新により、ラベル podSecurityLabelSync = false がセキュリティーラベルを保持するようになります。コレクター Pod は期待どおりにデプロイされます。(LOG-3340)
  • この更新の前は、コンソールビュープラグインがクラスターで有効になっていない場合でも、Operator はコンソールビュープラグインをインストールしていました。これにより、Operator がクラッシュしました。今回の更新により、クラスターのアカウントでコンソールビューが有効になっていない場合、Operator は正常に機能し、コンソールビューをインストールしなくなりました。(LOG-3407)
  • この更新の前は、Elasticsearch デプロイメントのステータスが更新されないリグレッションに対応するための以前の修正が原因で、Red Hat Elasticsearch Operator がデプロイされていない限り、Operator がクラッシュしていました。今回の更新により、その修正が元に戻されたため、Operator は安定した状態になりました。ただし、報告されたステータスに関連する以前の問題が再び発生するようになりました。(LOG-3428)
  • この更新の前は、Loki Operator は、選択されたスタックサイズに関係なく、LokiStack ゲートウェイのレプリカを 1 つだけデプロイしていました。今回の更新により、選択したサイズに応じてレプリカの数が正しく設定されるようになりました。(LOG-3478)
  • この更新の前は、複数のラベルキーに同じ接頭辞があり、一部のキーにドットが含まれていると、Elasticsearch に書き込まれたレコードで障害が発生していました。今回の更新により、ラベルキーのドットがアンダースコアに置き換えられ、問題が解決されました。(LOG-3341)
  • この更新の前は、ロギングビュープラグインに、OpenShift Container Platform の特定のバージョンと互換性のない機能が含まれていました。今回の更新で、プラグインの正しいリリースストリームにより、この問題は解決されます。(LOG-3467)
  • この更新の前は、ClusterLogForwarder カスタムリソースの調整で、1 つ以上のパイプラインの低下ステータスが誤って報告され、コレクター Pod が 8 - 10 秒ごとに再起動していました。今回の更新により、ClusterLogForwarder カスタムリソースの調整が正しく処理されるようになり、問題が解決されました。(LOG-3469)
  • この変更の前は、ClusterLogForwarder カスタムリソースの outputDefaults フィールドの仕様は、宣言されたすべての Elasticsearch 出力タイプに設定を適用していました。今回の変更により、拡張仕様に一致するように動作が修正され、デフォルトのマネージド Elasticsearch ストアにのみ設定が適用されるようになりました。(LOG-3342)
  • この更新の前は、OpenShift CLI (oc) がそのキャッシュを構築するために書き込み権限を持つフォルダーを必要とするため、OpenShift CLI (oc) の must-gather スクリプトが完了しませんでした。今回の更新により、OpenShift CLI (oc) にフォルダーへの書き込み権限が付与され、must-gather スクリプトが正常に完了するようになりました。(LOG-3472)
  • この更新の前は、Loki Operator Webhook サーバーが TLS エラーを引き起こしていました。今回の更新により、Loki Operator Webhook PKI は Operator Lifecycle Manager の動的 Webhook 管理によって管理されるようになり、問題が解決されました。(LOG-3511)

1.15.2. CVE

1.16. ロギング 5.5.5

本リリースには、OpenShift Logging バグ修正リリース 5.5.5 が含まれます。

1.16.1. バグ修正

  • この更新の前は、Kibana の OAuth cookie の有効期限は 24h に固定されていたため、accessTokenInactivityTimeout フィールドが 24h 未満の値に設定されていると、Kibana で 401 エラーが発生していました。今回の更新により、Kibana の OAuth cookie の有効期限が accessTokenInactivityTimeout に同期され、デフォルト値は 24h になります。(LOG-3305)
  • この更新の前は、Vector は、JSON 解析が有効になっている場合に、structuredTypeKey または structuredTypeName の値も定義せずにメッセージフィールドを解析していました。今回の更新により、構造化ログを Elasticsearch に書き込むときに、structuredTypeKey または structuredTypeName のいずれかに値が必要になりました。(LOG-3284)
  • この更新の前は、FluentdQueueLengthIncreasing アラート式から返された一連のラベルにカーディナリティの問題があった場合に、このアラートが発生しない可能性がありました。今回の更新により、アラートに必要なラベルのみが含まれるようにラベルが削減されました。(LOG-3226)
  • この更新の前は、Loki は、切断されたクラスター内の外部ストレージへのアクセスをサポートしていませんでした。今回の更新では、これらの接続をサポートするために、プロキシー環境変数とプロキシーの信頼できる CA バンドルがコンテナーイメージに含まれています。(LOG-2860)
  • 今回の更新前は、OpenShift Container Platform Web コンソールのユーザーは、Loki の CA 証明書を含む ConfigMap オブジェクトを選択できなかったため、Pod が CA なしで動作していました。今回の更新により、Web コンソールユーザーは設定マップを選択できるようになり、問題が解決されました。(LOG-3310)
  • この更新の前に、CA キーは CA を Loki にマウントするためのボリューム名として使用されていたため、CA キーに非準拠の文字 (ドットなど) が含まれているとエラー状態が発生していました。今回の更新により、ボリューム名が内部文字列に標準化され、問題が解決されました。(LOG-3332)

1.16.2. CVE

1.17. ロギング 5.5.4

本リリースには、RHSA-2022:7434-OpenShift Logging バグ修正リリース 5.5.4 が含まれます。

1.17.1. バグ修正

  • この更新の前は、ロギングビュープラグインのクエリーパーサーのエラーにより、クエリーに中かっこ {} が含まれている場合、ログクエリーの一部が消えていました。これにより、クエリーが無効になり、有効なクエリーに対してエラーが返されました。今回の更新により、パーサーはこれらのクエリーを正しく処理するようになりました。(LOG-3042)
  • この更新の前は、Elasticsearch または Kibana デプロイメントのステータスが変更されている間に、Operator がコレクターデーモンセットの削除と再作成のループに入る可能性がありました。今回の更新では、Operator のステータス処理が修正され、問題が解決されました。(LOG-3049)
  • この更新の前は、Vector のコレクターの実装をサポートするためにアラートが実装されていませんでした。この変更により、Vector アラートが追加され、選択したコレクターの実装に応じて個別のアラートがデプロイメントされます。(LOG-3127)
  • この更新の前は、Elasticsearch Operator のシークレット作成コンポーネントが内部シークレットを常に変更していました。今回の更新により、既存のシークレットが適切に処理されるようになりました。(LOG-3138)
  • この更新の前に、ログ must-gather スクリプトの以前のリファクタリングにより、アーティファクトの予想される場所が削除されました。この更新により、アーティファクトを /must-gather フォルダーに書き込むという変更が元に戻ります。(LOG-3213)
  • この更新の前は、特定のクラスターで、Prometheus エクスポーターが IPv6 ではなく IPv4 にバインドしていました。この更新後、Fluentd は IP バージョンを検出し、IPv4 の場合は 0.0.0.0、IPv6 の場合は [::] にバインドします。(LOG-3162)

1.17.2. CVE

1.18. ロギング 5.5.3

本リリースには、OpenShift Logging バグ修正リリース 5.5.3 が含まれます。

1.18.1. バグ修正

  • この更新前は、構造化されたメッセージを含むログエントリーに元のメッセージフィールドが含まれていたため、エントリーが大きくなりました。この更新により、構造化ログのメッセージフィールドが削除され、増加したサイズが縮小されます。(LOG-2759)
  • この更新の前に、コレクター設定は、Collector、default-log-store、および visualization Pod からログを除外していましたが、.gz ファイルにアーカイブされたログを除外できませんでした。今回の更新により、collector、default-log-store、および visualization Pod の .gz ファイルとして保存されたアーカイブログも除外されます。(LOG-2844)
  • この更新の前は、使用できない Pod へのリクエストがゲートウェイ経由で送信された場合、中断を警告するアラートはありませんでした。今回の更新により、ゲートウェイで書き込みまたは読み取り要求の完了に問題が発生した場合に、個別のアラートが生成されます。(LOG-2884)
  • この更新の前は、値が参照によってパイプラインを通過したため、Pod メタデータは fluent プラグインによって変更される可能性がありました。この更新により、各ログメッセージが Pod メタデータのコピーを確実に受信するようになり、各メッセージが個別に処理されるようになりました。(LOG-3046)
  • この更新の前に、OpenShift コンソールログビューで 不明な 重大度を選択すると、level=unknown 値のログが除外されていました。今回の更新により、レベルのないログと level=unknown の値を持つログが、不明な 重大度でフィルタリングすると表示されるようになりました。(LOG-3062)
  • この更新の前は、Elasticsearch に送信されたログレコードには、ログを送信する必要があるインデックスの名前を含む write-index という名前の追加フィールドがありました。このフィールドは、データモデルの一部ではありません。この更新後、このフィールドは送信されなくなりました。(LOG-3075)
  • 新しい組み込み Pod Security Admission Controller の導入により、グローバルまたは namespace レベルで定義された強制セキュリティー規格に従って設定されていない Pod は実行できません。今回の更新により、Operator と Collector は特権実行を許可し、セキュリティー監査の警告やエラーなしで実行できるようになりました。(LOG-3077)
  • この更新の前に、LokiStack をデフォルトのログストレージとして使用する場合、Operator は ClusterLogForwarder カスタムリソースで定義されたカスタム出力を削除しました。今回の更新により、Operator は ClusterLogForwarder カスタムリソースの処理時にカスタム出力をデフォルト出力とマージします。(LOG-3095)

1.18.2. CVE

1.19. Logging 5.5.2

本リリースには、OpenShift Logging バグ修正リリース 5.5.2 が含まれます。

1.19.1. バグ修正

  • 今回の更新以前は、Fluentd コレクターのアラートルールは OpenShift Container Platform モニタリングスタイルのガイドラインに準拠していませんでした。今回の更新により、これらのアラートが namespace ラベルを含むように変更され、問題が解決されました。(LOG-1823)
  • この更新の前は、インデックス名に複数のハイフン文字が含まれていると、インデックス管理ロールオーバースクリプトが新しいインデックス名を生成できませんでした。今回の更新により、インデックス名が正しく生成されるようになりました。(LOG-2644)
  • この更新の前は、Kibana ルートは証明書が存在しない状態で caCertificate 値を設定していました。今回の更新により、caCertificate 値が設定されなくなりました。(LOG-2661)
  • この更新の前は、コレクターの依存関係の変更により、未使用のパラメーターに対して警告メッセージが発行されていました。今回の更新で、未使用の設定パラメーターを削除すると、問題が解決されます。(LOG-2859)
  • この更新の前に、Loki Operator が作成したデプロイメント用に作成された Pod は、Operator が実行されているクラスターでそのようなノードが利用可能な場合、Linux 以外のオペレーティングシステムのノードで誤ってスケジュールされていました。今回の更新により、Operator は追加のノードセレクターを Pod 定義に割り当て、Linux ベースのノードでのみ Pod をスケジュールできるようにします。(LOG-2895)
  • この更新の前は、LokiStack ゲートウェイの LogQL パーサーの問題により、OpenShift コンソールのログビューはログを重大度でフィルタリングしませんでした。今回の更新では、パーサーの修正により問題が解決され、OpenShift コンソールのログビューは重大度でフィルタリングできるようになりました。(LOG-2908)
  • この更新の前に、Fluentd コレクタープラグインのリファクタリングにより、イベントのタイムスタンプフィールドが削除されました。この更新により、イベントの受信時刻をソースとするタイムスタンプフィールドが復元されます。(LOG-2923)
  • この更新の前は、監査ログに level フィールドがないため、ベクターログでエラーが発生していました。今回の更新で、監査ログレコードに level フィールドが追加され、問題が解決されました。(LOG-2961)
  • 今回の更新の前は、Kibana カスタムリソースを削除した場合、OpenShift Container Platform Web コンソールは引き続き Kibana へのリンクを表示していました。今回の更新で、Kibana カスタムリソースを削除すると、そのリンクも削除されます。(LOG-3053)
  • この更新の前は、ClusterLogForwarder カスタムリソースに JSON 解析が定義されている場合、各ロールオーバージョブで空のインデックスが作成されていました。今回の更新により、新しいインデックスは空ではなくなりました。(LOG-3063)
  • この更新の前に、ユーザーが Loki Operator 5.5 への更新後に LokiStack を削除すると、もともと Loki Operator 5.4 によって作成されたリソースが残りました。今回の更新により、リソースの所有者参照は 5.5 LokiStack を指します。(LOG-2945)
  • この更新の前は、ユーザーはアクセス権を持つ namespace のアプリケーションログを表示できませんでした。今回の更新により、Loki Operator はクラスターロールとクラスターロールバインディングを自動的に作成し、ユーザーがアプリケーションログを読み取れるようにします。(LOG-2918)
  • この更新の前は、cluster-admin 権限を持つユーザーは、ログコンソールを使用してインフラストラクチャーと監査ログを適切に表示できませんでした。今回の更新により、認可チェックが拡張され、cluster-admin および dedicated-admin グループのユーザーも管理者として認識されるようになりました。(LOG-2970)

1.19.2. CVE

1.20. Logging 5.5.1

本リリースには OpenShift Logging バグ修正リリース 5.5.1 が含まれます。

1.20.1. 機能拡張

  • 今回の機能拡張により、Logging Console プラグインが使用されている場合に、Aggregated Logs タブが OpenShift Container Platform Web コンソールの Pod Details ページに追加されました。この拡張機能は OpenShift Container Platform 4.10 以降でのみ利用できます。(LOG-2647)
  • 今回の機能拡張により、ログ転送の出力オプションとして Google Cloud Logging が追加されました。(LOG-1482)

1.20.2. バグ修正

  • 今回の更新以前は、Operator は Pod が準備状態にあることを確認しないことが原因で、クラスターの再起動時にクラスターが動作不能な状態になりました。今回の更新により、Operator は、再起動中に新しい Pod を準備完了としてマークしてから新しい Pod に移動を続けることで、問題を解決します。(LOG-2745)
  • 今回の更新以前は、Fluentd は Kubernetes プラットフォームがログファイルをローテーションしたことを認識しない場合があり、ログメッセージを読み取らなくなっていました。今回の更新で、アップストリームの開発チームが提案する設定パラメーターを設定することにより修正されています。(LOG-2995)
  • 今回の更新以前は、複数行のエラー検出機能が追加されたことが原因で、内部ルーティングが変更され、レコードが間違った宛先に転送されていました。今回の更新により、内部ルーティングが正しくなりました。(LOG-2801)
  • 今回の更新前は、OpenShift Container Platform Web コンソールの更新間隔を変更すると、Query フィールドが空の場合にはエラーが発生していました。今回の更新で、Query フィールドが空の場合に、間隔の変更が選択不可能になりました。(LOG-2917)

1.20.3. CVE

1.21. Logging 5.5

Logging 5.5 については、次のアドバイザリーを利用できます (リリース 5.5)。

1.21.1. 機能拡張

  • 今回の更新では、構造化ログを同じ Pod 内の異なるコンテナーからさまざまなインデックスに転送できるようになりました。この機能を使用するには、複数コンテナーのサポートを使用してパイプラインを設定し、Pod にアノテーションを付ける必要があります。(LOG-1296)
重要

ログの JSON 形式は、アプリケーションによって異なります。作成するインデックスが多すぎるとパフォーマンスに影響するため、この機能の使用は、互換性のない JSON 形式のログのインデックスの作成に限定してください。クエリーを使用して、さまざまな namespace または互換性のある JSON 形式のアプリケーションからログを分離します。

  • 今回の更新では、Kubernetes 共通ラベルである app.kubernetes.io/component、app.kubernetes.io/managed-by、app.kubernetes.io/part-of、および app.kubernetes.io/version を使用して、Elasticsearch 出力でログをフィルターリングできます。.Elasticsearch 以外の出力タイプでは、kubernetes.labels に含まれるすべてのラベルを使用できます。(LOG-2388)
  • 今回の更新では、AWS Security Token Service (STS) が有効になっているクラスターは、STS 認証を使用してログを Amazon CloudWatch に転送できます。(LOG-1976)
  • 今回の更新では、'Loki Operator' Operator および Vector コレクターがテクニカルプレビュー機能から一般提供機能 (GA) に移行します。以前のリリースとの完全な機能パリティーに関しては作業中で、一部の API はテクニカルプレビュー機能のままです。詳細については LokiStack を使用したロギング のセクションを参照してください。

1.21.2. バグ修正

  • この更新の前は、ログを Amazon CloudWatch に転送するように設定されたクラスターが、拒否されたログファイルを一時ストレージに書き込んでいたため、時間の経過とともにクラスターが不安定になりました。今回の更新により、すべてのストレージオプションの一括バックアップが無効になり、問題が解決されました。(LOG-2746)
  • 今回の更新以前に、Operator は、非推奨で OpenShift Container Platform の今後のバージョンで削除予定の API のバージョンを一部使用していました。今回の更新により、依存関係がサポート対象の API バージョンに移動されます。(LOG-2656)

今回の更新以前に、Operator は、非推奨で OpenShift Container Platform の今後のバージョンで削除予定の API のバージョンを一部使用していました。今回の更新により、依存関係がサポート対象の API バージョンに移動されます。(LOG-2656)

  • 今回の更新以前は、複数行エラー検出用に設定された複数の ClusterLogForwarder パイプラインにより、コレクターが crashloopbackoff エラー状態になりました。今回の更新により、複数の設定セクションに同じ一意の ID が使用される問題が修正されます。(LOG-2241)
  • この更新の前は、コレクターは UTF-8 以外の記号を Elasticsearch ストレージログに保存できませんでした。今回の更新で、コレクターは UTF-8 以外の記号をエンコードし、問題を解決しました。(LOG-2203)
  • 今回の更新以前は、ラテン文字以外の文字が Kibana で正しく表示されませんでした。今回の更新により、Kibana はすべての有効な UTF-8 シンボルを正しく表示します。(LOG-2784)

1.21.3. CVE

1.22. Logging 5.4.11

このリリースには、OpenShift Logging バグ修正リリース 5.4.11 が含まれます。

1.22.1. バグ修正

1.22.2. CVE

1.23. Logging 5.4.10

このリリースには、OpenShift Logging バグ修正リリース 5.4.10 が含まれます。

1.23.1. バグ修正

なし。

1.23.2. CVE

1.24. ロギング 5.4.9

本リリースには、OpenShift Logging バグ修正リリース 5.4.9 が含まれます。

1.24.1. バグ修正

  • この更新の前は、Fluentd コレクターは未使用の設定パラメーターを警告していました。この更新により、これらの設定パラメーターとその警告メッセージが削除されます。(LOG-3074)
  • この更新の前は、Kibana の OAuth cookie の有効期限は 24h に固定されていたため、accessTokenInactivityTimeout フィールドが 24h 未満の値に設定されていると、Kibana で 401 エラーが発生していました。今回の更新により、Kibana の OAuth cookie の有効期限が accessTokenInactivityTimeout に同期され、デフォルト値は 24h になります。(LOG-3306)

1.24.2. CVE

1.25. ロギング 5.4.8

本リリースには、RHSA-2022:7435-OpenShift Logging バグ修正リリース 5.4.8 が含まれます。

1.25.1. バグ修正

なし。

1.25.2. CVE

1.26. Logging 5.4.6

本リリースには、OpenShift Logging バグ修正リリース 5.4.6 が含まれます。

1.26.1. バグ修正

  • 今回の更新以前は、Fluentd は Kubernetes プラットフォームがログファイルをローテーションしたことを認識しない場合があり、ログメッセージを読み取らなくなっていました。今回の更新で、アップストリームの開発チームが提案する設定パラメーターを設定することにより修正されています。(LOG-2792)
  • この更新の前は、ClusterLogForwarder カスタムリソースに JSON 解析が定義されている場合、各ロールオーバージョブで空のインデックスが作成されていました。今回の更新により、新しいインデックスは空ではなくなりました。(LOG-2823)
  • 今回の更新の前は、Kibana カスタムリソースを削除した場合、OpenShift Container Platform Web コンソールは引き続き Kibana へのリンクを表示していました。今回の更新で、Kibana カスタムリソースを削除すると、そのリンクも削除されます。(LOG-3054)

1.26.2. CVE

1.27. ロギング 5.4.5

本リリースには、RHSA-2022:6183-OpenShift Logging バグ修正リリース 5.4.5 が含まれます。

1.27.1. バグ修正

  • 今回の更新以前は、Operator は Pod が準備状態にあることを確認しないことが原因で、クラスターの再起動時にクラスターが動作不能な状態になりました。今回の更新により、Operator は、再起動中に新しい Pod を準備完了としてマークしてから新しい Pod に移動を続けることで、問題を解決します。(LOG-2881)
  • 今回の更新以前は、複数行のエラー検出機能が追加されたことが原因で、内部ルーティングが変更され、レコードが間違った宛先に転送されていました。今回の更新により、内部ルーティングが正しくなりました。(LOG-2946)
  • 今回の更新以前は、Operator は引用符で囲まれたブール値でインデックス設定 JSON 応答をデコードできず、エラーが発生していました。今回の更新により、Operator はこの JSON 応答を適切にデコードできるようになりました。(LOG-3009)
  • この更新の前に、Elasticsearch インデックステンプレートは、ラベルのフィールドを間違ったタイプで定義していました。この変更により、これらのテンプレートが更新され、ログコレクターによって転送されると予想されるタイプと同じになりました。(LOG-2972)

1.27.2. CVE

1.28. Logging 5.4.4

本リリースには、RHBA-2022:5907-OpenShift Logging バグ修正リリース 5.4.4 が含まれます。

1.28.1. バグ修正

  • 今回の更新以前は、ラテン文字以外の文字が Elasticsearch で正しく表示されませんでした。今回の更新により、Elasticsearch はすべての有効な UTF-8 シンボルを正しく表示します。(LOG-2794)
  • 今回の更新以前は、ラテン文字以外の文字が Fluentd で正しく表示されませんでした。今回の更新により、Fluentd はすべての有効な UTF-8 シンボルを正しく表示します。(LOG-2657)
  • この更新以前には、コレクターのメトリックサーバーは、環境値によって公開された値を使用してアドレスにバインドしようとしました。今回の変更により、使用可能なインターフェイスであればどれでもバインドするように設定が変更されます。(LOG-2821)
  • 今回の更新以前は、cluster-logging Operator はクラスターに依存してシークレットを作成していました。このクラスターの動作は OpenShift Container Platform 4.11 で変更されたことが原因で、ロギングデプロイメントに失敗しました。今回の更新により、cluster-logging Operator は必要に応じてシークレットを作成することで問題を解決します。(LOG-2840)

1.28.2. CVE

1.29. Logging 5.4.3

本リリースには、RHSA-2022:5556-OpenShift Logging Bug Fix Release 5.4.3 が含まれます。

1.29.1. Elasticsearch Operator の非推奨通知

logging サブシステム 5.4.3 では、Elasticsearch Operator は非推奨となり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

1.29.2. バグ修正

  • この更新の前は、OpenShift ロギングダッシュボードは、アクティブなすべてのシャードではなく、アクティブなプライマリーシャードの数を表示していました。今回の更新により、ダッシュボードにはすべてのアクティブなシャードが表示されます。(LOG-2781)
  • この更新に、elasticsearch-operator が使用するライブラリーのバグには、DoS 攻撃の脆弱性が含まれていました。今回の更新により、ライブラリーがこの脆弱性を含まないバージョンに更新されました。(LOG-2816)
  • 今回の更新以前は、ログを Loki に転送するように Vector を設定するときに、Loki で TLS が有効になっている場合には、カスタムベアラートークンを設定したり、デフォルトトークンを使用したりすることができませんでした。今回の更新により、Vector は TLS が有効なトークンを使用してログを Loki に転送できるようになりました。(LOG-2786
  • 今回の更新以前に、ElasticSearch Operator は、oauth-proxy イメージを選択するときに、ImageStream カスタムリソースの referencePolicy プロパティーを省略していました。このようにプロパティーが省略されることが原因で特定の環境で Kibana のデプロイに失敗しました。今回の更新では、referencePolicy を使用することで問題が解決され、Operator は Kibana を正常にデプロイできるようになりました。(LOG-2791)
  • 今回の更新以前は、ClusterLogForwarder カスタムリソースのアラートルールで、複数の転送出力が考慮されていませんでした。今回の更新で問題が解決されました。(LOG-2640)
  • この更新の前は、ログを Amazon CloudWatch に転送するように設定されたクラスターが、拒否されたログファイルを一時ストレージに書き込んでいたため、時間の経過とともにクラスターが不安定になりました。今回の更新により、CloudWatch のチャンクバックアップが無効になり、問題が解決されました。(LOG-2768)

1.29.3. CVE

1.30. Logging 5.4.2

本リリースには、RHBA-2022:4874-OpenShift Logging バグ修正リリース 5.4.2 が含まれます。

1.30.1. バグ修正

  • 今回の更新以前は、空白の使用に一貫性がなかったため、oc edit を使用したコレクター設定の編集が困難でした。今回の変更により、Operator による更新の前に設定を正規化およびフォーマットするロジックが導入され、oc edit を使用して簡単に編集できるようになりました。(LOG-2319)
  • 今回の更新以前は、FluentdNodeDown アラートは、メッセージセクションにインスタンスラベルを適切に提供できませんでした。今回の更新では、部分的なインスタンスエラーの場合にインスタンスラベルを提供するようにアラートルールを修正することで、問題を解決します。(LOG-2607)
  • 今回の更新以前は、`critical` などの複数のログレベルで、ドキュメントにはサポート対象と記載されているにも拘らず、サポートされていませんでした。今回の更新により不一致が修正され、記載されているログレベルが製品でサポートされるようになりました。(LOG-2033)

1.30.2. CVE

1.31. Logging 5.4.1

このリリースには、RHSA-2022:2216-OpenShift Logging Bug Fix Release 5.4.1 が含まれます。

1.31.1. バグ修正

  • この更新の前は、ログファイルメトリックエクスポーターは、エクスポーターの実行中に作成されたログのみを報告したため、ログの増加データが不正確になりました。この更新では、/var/log/pods をモニターすることでこの問題を解決しています。(LOG-2442)
  • この更新の前は、コレクターは、ログを fluentd の転送レシーバーに転送するときに古い接続を継続的に使用しようとしたため、ブロックされていました。このリリースでは、keepalive_timeout 値が 30 秒 (30s) に設定されているため、コレクターは接続をリサイクルし、適切な時間内に失敗したメッセージの送信を再試行します。(LOG-2534)
  • この更新の前は、ログを読み取るためのテナンシーを強制するゲートウェイコンポーネントのエラーにより、Kubernetes namespace を持つログへのアクセスが制限され、監査ログと一部のインフラストラクチャーログが読み取れなくなることがありました。この更新により、プロキシーは管理者アクセス権を持つユーザーを正しく検出し、namespace なしでログへのアクセスを許可します。(LOG-2448)
  • 今回の更新の前は、system:serviceaccount:openshift-monitoring:prometheus-k8s サービスアカウントには、clusterrole および clusterrolebinding としてクラスターレベルの特権がありました。今回の更新により、ロールとロールバインディングを持つ openshift-logging namespace にサービスアカウントが制限されます。(LOG-2437)
  • この更新の前は、Linux 監査ログの時間解析は、キーと値のペアの順序に依存していました。この更新により、時間エントリーを見つけるために正規表現を使用するように解析が変更されます。(LOG-2321)

1.31.2. CVE

1.32. Logging 5.4

以下のアドバイザリーは、ロギング 5.4 に使用できます Logging subsystem for Red Hat OpenShift Release 5.4

1.32.1. テクノロジープレビュー

重要

Vector はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.32.2. Vector について

Vector は、ロギングサブシステムの現在のデフォルトコレクターに代わるテクノロジープレビューとして提供されるログコレクターです。

次の出力がサポートされています。

  • elasticsearch。外部 Elasticsearch インスタンス。elasticsearch 出力では、TLS 接続を使用できます。
  • kafka。Kafka ブローカー。kafka 出力は、セキュリティーで保護されていない接続または TLS 接続を使用できます。
  • loki。Loki: 水平方向にスケーラブルで可用性の高いマルチテナントログ集計システム。

1.32.2.1. Vector の有効化

Vector はデフォルトでは有効になっていません。以下のステップを使用して、OpenShift Container Platform クラスターで Vector を有効にします。

重要

Vector は、FIPS 対応クラスターをサポートしていません。

前提条件

  • OpenShift Container Platform: 4.12
  • Red Hat OpenShift のロギングサブシステム: 5.4
  • FIPS が無効

手順

  1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。 

    $ oc -n openshift-logging edit ClusterLogging instance
  2. logging.openshift.io/preview-vector-collector: enabled アノテーションを ClusterLogging カスタムリソース (CR) に追加します。
  3. ClusterLogging カスタムリソース (CR) にコレクションタイプとして vector を追加します。 
  apiVersion: "logging.openshift.io/v1"
  kind: "ClusterLogging"
  metadata:
    name: "instance"
    namespace: "openshift-logging"
    annotations:
      logging.openshift.io/preview-vector-collector: enabled
  spec:
    collection:
      logs:
        type: "vector"
        vector: {}

関連情報

重要

Loki Operator はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.32.3. Loki について

Loki は、水平方向にスケーラブルで可用性の高いマルチテナントログ集約システムであり、現在、ロギングサブシステムのログストアとして Elasticsearch の代替として提供されています。

関連情報

1.32.3.1. Lokistack のデプロイ

OpenShift Container Platform コンソールを使用して Loki Operator をインストールできます。

前提条件

  • OpenShift Container Platform: 4.12
  • Red Hat OpenShift のロギングサブシステム: 5.4

OpenShift Container PlatformWeb コンソールを使用して Loki Operator をインストールするには:

  1. Loki Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
    2. 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
    3. Installation Mode で、All namespaces on the cluster を選択します。

    4. Installed Namespace で、openshift-operators-redhat を選択します。

      openshift-operators-redhat namespace を指定する必要があります。openshift-operators namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。

    5. Enable operator recommended cluster monitoring on this namespace を選択します。

      このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニターリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

    6. Approval Strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
    7. Install をクリックします。
    8. Loki Operator がインストールされていることを確認します。Operators → Installed Operators ページにアクセスして、"Loki Operator" を探します。
    9. Status が Succeeded であるすべてのプロジェクトに Loki Operator がリストされていることを確認します。

1.32.4. バグ修正

  • 今回の更新以前は、cluster-logging-operator は、クラスタースコープのロールとバインディングを利用して、Prometheus サービスアカウントがメトリックをスクレープするための権限を確立していました。これらの権限は、コンソールインターフェイスを使用して Operator をデプロイする時にだけ作成され、コマンドラインから この Operator をデプロイする場合には欠落していました。この更新では、ロールとバインディングを namespace スコープにすることで問題を修正しています。(LOG-2286)
  • この更新の前に、ダッシュボードの調整を修正するための変更により、namespace 全体のリソースに ownerReferences フィールドが導入されました。その結果、設定マップとダッシュボードの両方が namespace に作成されませんでした。今回の更新では、ownerReferences フィールドを削除すると問題が解決し、コンソールで OpenShift Logging ダッシュボードを使用できるようになります。(LOG-2163)
  • 今回の更新以前は、cluster-logging-operator でダッシュボードなど、既存の Config Map と目的の Config Map が正しく比較されなかったため、メトリックダッシュボードへの変更がデプロイされていませんでした。この更新では、オブジェクトラベルに一意のハッシュ値を追加することで問題が解決します。(LOG-2071)
  • この更新の前は、OpenShift Logging ダッシュボードは、過去 24 時間に収集された上位のコンテナーを表示するテーブルに pod と namespace を正しく表示しませんでした。今回の更新では、pod と namespace が正しく表示されます。(LOG-2069)
  • この更新の前は、ClusterLogForwarder が Elasticsearch OutputDefault で設定されていて、Elasticsearch 出力に構造化キーがなかった場合、生成された設定に認証用の誤った値が含まれていました。この更新では、使用されているシークレットと証明書が修正されます。(LOG-2056)
  • この更新以前は、無効なメトリックへの参照が原因で、OpenShift Logging ダッシュボードに空の CPU グラフが表示されていました。この更新により、正しいデータポイントが選択され、問題が解決されました。(LOG-2026)
  • 今回の更新以前は、Fluentd コンテナーイメージには、実行時に不要なビルダーツールが含まれていました。この更新により、これらのツールがイメージから削除されます。.(LOG-1927)
  • この更新の前は、5.3 リリースでデプロイされたコレクターの名前が変更されたため、ロギングコレクターは FluentdNodeDown アラートを生成していました。この更新では、Prometheus アラートのジョブ名を修正することで問題を解決しています。(LOG-1918)
  • この更新の前は、コンポーネント名の変更のリファクタリングのために、ログコレクターは独自のログを収集していました。これにより、コレクターが自身のログを処理する潜在的なフィードバックループが発生し、メモリーとログメッセージのサイズの問題が発生する可能性があります。この更新では、コレクターログをコレクションから除外することで問題を解決しています。(LOG-1774)
  • この更新の前では、PVC がすでに存在する場合、Unable to create PersistentVolumeClaim due to forbidden: exceeded quota: infra-storage-quota というエラーを生成していました。この更新により、Elasticsearch は既存の PVC をチェックし、問題を解決します。(LOG-2131)
  • この更新の前は、elasticsearch-signing シークレットが削除されたときに Elasticsearch は準備完了状態に戻ることができませんでした。この更新により、Elasticsearch は、そのシークレットが削除された後、準備完了状態に戻ることができます。(LOG-2171)
  • この更新の前は、コレクターがコンテナーログを読み取るパスが変更されたため、コレクターは一部のレコードを間違ったインデックスに転送していました。この更新により、コレクターは正しい設定を使用して問題を解決するようになりました。(LOG-2160)
  • この更新の前は、namespace のリストがヘッダーサイズの最大制限に達したため、namespace が多数あるクラスターにより、Elasticsearch はリクエストの処理を停止していました。この更新により、ヘッダーには namespace 名のリストのみが含まれるようになり、問題が解決されました。(LOG-1899)
  • この更新の前は、OpenShift Container Platform Logging ダッシュボードには、Elasticsearch に x ノードがある場合の実際の値の x 倍のシャードの数が表示されていました。この問題は、出力は常に Elasticsearch クラスター全体に対するものであったにも拘らず、Elasticsearch Pod ごとにすべてのプライマリーシャードを出力し、その合計を計算していたために発生しました。この更新により、シャードの数が正しく計算されるようになりました。(LOG-2156)
  • この更新の前は、シークレット kibana と kibana-proxy は手動で削除された場合、再作成されませんでした。この更新により、elasticsearch-operator はリソースを監視し、削除された場合は自動的に再作成します。(LOG-2250)
  • この更新の前に、バッファーチャンクサイズを調整すると、コレクターは、チャンクサイズがイベントストリームのバイト制限を超えているという警告を生成する可能性がありました。この更新では、読み取り行の制限を調整して、問題を解決することもできます。(LOG-2379)
  • 今回の更新以前には、OpenShift WebConsole のロギングコンソールリンクが ClusterLogging CR で削除されていませんでした。この更新により、CR を削除するか、Cluster Logging Operator をアンインストールするとリンクが削除されます。(LOG-2373)
  • 今回の更新以前は、コンテナーログパスを変更すると、元のパスで設定された古いリリースでは、このコレクションメトリックは常にゼロになりました。この更新では、収集されたログに関するメトリックを公開するプラグインが、問題を解決するためにいずれかのパスからの読み取りをサポートします。(LOG-2462)

1.32.5. CVE

1.33. ロギング 5.3.14

本リリースには、OpenShift Logging バグ修正リリース 5.3.14 が含まれます。

1.33.1. バグ修正

  • この更新の前に、log-file-metrics-exporter コンポーネントによって生成されたログファイルサイズマップは、削除されたファイルのエントリーを削除しなかったため、ファイルサイズとプロセスメモリーが増加していました。今回の更新により、ログファイルサイズマップに、削除されたファイルのエントリーが含まれなくなりました。(LOG-3293)

1.33.2. CVE

1.34. ロギング 5.3.13

本リリースには、RHSA-2022:68828-OpenShift Logging バグ修正リリース 5.3.13 が含まれます。

1.34.1. バグ修正

なし。

1.34.2. CVE

1.35. Logging 5.3.12

本リリースには、OpenShift Logging バグ修正リリース 5.3.12 が含まれます。

1.35.1. バグ修正

なし。

1.35.2. CVE

1.36. ロギング 5.3.11

本リリースには、OpenShift Logging バグ修正リリース 5.3.11 が含まれます。

1.36.1. バグ修正

  • 今回の更新以前は、Operator は Pod が準備状態にあることを確認しないことが原因で、クラスターの再起動時にクラスターが動作不能な状態になりました。今回の更新により、Operator は、再起動中に新しい Pod を準備完了としてマークしてから新しい Pod に移動を続けることで、問題を解決します。(LOG-2871)

1.36.2. CVE

1.37. Logging 5.3.10

このリリースには、RHSA-2022:5908-OpenShift Logging バグ修正リリース 5.3.10 が含まれます。

1.37.1. バグ修正

1.37.2. CVE

1.38. Logging 5.3.9

本リリースには、RHBA-2022:5557-OpenShift Logging バグ修正リリース 5.3.9 が含まれます。

1.38.1. バグ修正

  • 今回の更新以前に、ロギングコレクターには、生成されたメトリクスのラベルとしてパスが含まれていました。このパスは頻繁に変更され、Prometheus サーバーのストレージが大幅に変更されました。今回の更新で、問題を解決し、ストレージの消費を減らすために、ラベルが削除されました。(LOG-2682)

1.38.2. CVE

1.39. Logging 5.3.8

本リリースには、RHBA-2022:5010-OpenShift Logging バグ修正リリース 5.3.8 が含まれます。

1.39.1. バグ修正

(なし。)

1.39.2. CVE

1.40. OpenShift Logging 5.3.7

このリリースには、RHSA-2022:2217 OpenShift Logging Bug Fix Release 5.3.7 が含まれます。

1.40.1. バグ修正

  • この更新の前は、Linux 監査ログの時間解析はキー/値ペアの順序に依存していました。この更新により、時間エントリーを見つけるために正規表現を利用するように解析が変更されます。(LOG-2322)
  • この更新以前には、一部のログフォワーダー出力は同じタイムスタンプでログを並べ替えることができました。この更新により、タイムスタンプが一致するエントリーを注文するためのシーケンス番号がログレコードに追加されました。(LOG-2334)
  • この更新の前は、namespace のリストがヘッダーサイズの最大制限に達したため、namespace が多数あるクラスターにより、Elasticsearch はリクエストの処理を停止していました。この更新により、ヘッダーには namespace 名のリストのみが含まれるようになり、問題が解決されました。(LOG-2450)
  • この更新の前は、system:serviceaccount:openshift-monitoring:prometheus-k8s には、clusterrole および clusterrolebinding としてクラスターレベルの特権がありました。この更新により、serviceaccount がロールとロールバインディングを持つ openshift-logging namespace に制限されます。(LOG-2481))

1.40.2. CVE

1.41. OpenShift Logging 5.3.6

本リリースには、RHBA-2022:1377 OpenShift Logging Bug Fix Release 5.3.6 が含まれます。

1.41.1. バグ修正

  • この更新の前は、キーなしで許容値を定義し、既存の Operator が原因で、Operator はアップグレードを完了できませんでした。今回の更新により、この許容範囲によってアップグレードの完了が妨げられることはなくなりました。(LOG-2126)
  • この変更の前は、コレクターがチャンクバイト制限が発行されたイベントを超えている場合に警告を生成することが可能でした。この変更により、アップストリームのドキュメントのアドバイスに従って、リードラインの制限を調整して問題を解決できます。(LOG-2380)

1.42. OpenShift Logging 5.3.5

このリリースには、RHSA-2022:0721 OpenShift Logging Bug Fix Release 5.3.5 が含まれます。

1.42.1. バグ修正

  • この更新の前は、OpenShift Container Platform から OpenShift Logging を削除した場合、Web コンソールは引き続き Logging ページへのリンクを表示していました。この更新では、OpenShift Logging を削除またはアンインストールするとそのリンクも削除されます。(LOG-2182)

1.42.2. CVE

1.43. OpenShift Logging 5.3.4

本リリースには、RHBA-2022:0411 OpenShift Logging Bug Fix Release 5.3.4 が含まれます。

1.43.1. バグ修正

  • この更新以前は、cluster-logging-operator でダッシュボードを含む既存の設定マップと目的の設定マップが正しく比較されなかったため、メトリックダッシュボードへの変更がまだデプロイされていませんでした。この更新では、オブジェクトラベルに一意のハッシュ値を追加することにより、ロジックを修正します。(LOG-2066)
  • この更新の前は、FIPS を有効にして更新した後、Elasticsearch Pod を起動できませんでした。この更新により、Elasticsearch Pod は正常に起動します。(LOG-1974)
  • この更新の前では、PVC がすでに存在する場合、Unable to create PersistentVolumeClaim due to forbidden: exceeded quota: infra-storage-quota. というエラーを生成していました。この更新により、elasticsearch は既存の PVC をチェックし、問題を解決します。(LOG-2127)

1.43.2. CVE

1.44. OpenShift Logging 5.3.3

本リリースには、RHSA-2022:0227 OpenShift Logging のバグ修正リリース 5.3.3 が含まれます。

1.44.1. バグ修正

  • 今回の更新以前は、cluster-logging Operator でダッシュボードを含む既存の設定マップと目的の設定マップが正しく比較されなかったため、メトリックダッシュボードへの変更がまだデプロイされていませんでした。この更新では、ダッシュボードの一意のハッシュ値をオブジェクトラベルに追加することで、ロジックを修正しています。(LOG-2066)
  • 今回の更新により、log4j の依存関係が 2.17.1 に変更され、 CVE-2021-44832 が解決されました。(LOG-2102)

1.44.2. CVE

例1.11 クリックして CVE を展開

1.45. OpenShift Logging 5.3.2

本リリースには、RHSA-2022:0044 OpenShift Logging のバグ修正リリース 5.3.2 が含まれます。

1.45.1. バグ修正

  • 今回の更新以前は、Elasticsearch は解析エラーが原因でイベントルーターからのログを拒否していました。今回の更新では、解析エラーを解決するようにデータモデルが変更されています。ただし、その結果、以前のインデックスが原因で Kibana 内で警告またはエラーが発生する可能性があります。kubernetes.event.metadata.resourceVersion フィールドが原因で、既存のインデックスが削除または再インデックスされるまでエラーが発生します。このフィールドが Kibana で使用されていない場合は、エラーメッセージを無視できます。古いインデックスを削除する保持ポリシーがある場合には、このポリシーにより、最終的に古いインデックスが削除されてエラーメッセージを停止します。それ以外の場合は、手動でインデックスを再作成してエラーメッセージを停止します。(LOG-2087)
  • 今回の更新以前は、OpenShift Logging Dashboard は、過去 24 時間に作成および収集されたコンテナーの上位を表示するテーブルに、間違った Pod の namespace を表示していました。今回の更新により、OpenShift Logging Dashboard に正しい Pod の namespace が表示されます。(LOG-2051)
  • この更新の前では、ClusterLogForwarder カスタムリソース (CR) インスタンスの outputDefaults.elasticsearch.structuredTypeKey に構造化キーがなかった場合、CR は出力シークレットをデフォルトのログストアとの通信に使用されるデフォルトのシークレットに置き換えていました。今回の更新では、定義された出力シークレットが正しく使用されます。(LOG-2046)

1.45.2. CVE

1.46. OpenShift Logging 5.3.1

本リリースには、RHSA-2021:5129 OpenShift Logging のバグ修正リリース 5.3.1 が含まれます。

1.46.1. バグ修正

  • 今回の更新以前は、Fluentd コンテナーイメージには、実行時に不要なビルダーツールが含まれていました。今回の更新により、これらのツールがイメージから削除されます。(LOG-1998)
  • 今回の更新以前は、無効なメトリックへの参照が原因で、ログダッシュボードに空の CPU グラフが表示されていました。今回の更新により、ロギングダッシュボードに CPU グラフが正しく表示されます。(LOG-1925)
  • 今回の更新以前は、Elasticsearch Prometheus エクスポータープラグインは、Elasticsearch ノードのパフォーマンスに影響を与える高コストのクエリーを使用してインデックスレベルのメトリックをコンパイルしていました。この更新で、パフォーマンスを向上させる、低コストのクエリーが実装されています。(LOG-1897)

1.46.2. CVE

1.47. OpenShift Logging 5.3.0

本リリースには、RHSA-2021:4627 OpenShift Logging のバグ修正リリース 5.3.0 が含まれます。

1.47.1. 新機能および機能拡張

  • この更新により、ログ転送の承認オプションが拡張されました。出力は、SASL、ユーザー名/パスワード、または TLS で設定できるようになりました。

1.47.2. バグ修正

  • 今回の更新以前は、syslog プロトコルを使用してログを転送した場合に、ルビーハッシュでエンコードされたキーと値のペアをシリアル化して⇒文字を含めてタブを #11 に置き換えました。今回の更新では、問題が修正され、有効な JSON としてログメッセージが正しくシリアル化されます。(LOG-1494)
  • 今回の更新以前は、複数行のエラー検出が有効な場合に、正しい Cloudwatch ストリームに転送されるように、アプリケーションログが正しく設定されていませんでした。(LOG-1939)
  • 今回の更新以前は、デプロイされたコレクターの名前が 5.3 リリースで変更されたため、アラート fluentnodedown が生成されていました。(LOG-1918)
  • 今回の更新以前は、1 つ前のリリース設定で発生したリグレッションが原因で、コレクターはシャットダウン前にバッファーされたメッセージをフラッシュしてコレクター Pod の終了と再起動を遅らせていました。今回の更新で、fluentd はシャットダウン時にバッファーをフラッシュしなくなり、問題が解決しました。(LOG-1735)
  • 今回の更新以前では、1 つ前のリリースで発生したリグレッションが原因で、JSON メッセージの解析が意図的に無効にされていました。今回の更新により、JSON 解析が再度有効になりました。また、解析された JSON メッセージの level フィールドをもとに、または正規表現を使用してメッセージフィールドから一致を抽出することで、ログエントリー level を設定します。(LOG-1199)
  • 今回の更新以前では、 Cluster Logging カスタムリソース (CR) は、必要なバッファースペースが使用できない場合でも、 total Limit Size フィールドの値を Fluentdtotal_limit_size フィールドに適用していました。今回の更新により、CR は 2 つの total Limit Size または 'default'値の小さい方を Fluentdtotal_limit_size フィールドに適用し、問題が解決されました。(LOG-1776)

1.47.3. 既知の問題

  • ログを外部 Elasticsearch サーバーに転送してから、ユーザー名とパスワードなどのパイプラインシークレットで設定された値を変更する場合に、Fluentd フォワーダーは新規シークレットを読み込むにもかかわらず、以前の値を使用して外部 Elasticsearch サーバーに接続します。この問題は、現在 Red Hat OpenShift Logging Operator がコンテンツの変更についてシークレットを監視しないために発生します。(LOG-1652)

    回避策として、シークレットを変更した場合には、以下を入力して Fluentd Pod を強制的に再デプロイできます。 

    $ oc delete pod -l component=collector

1.47.4. 非推奨および削除された機能

以前のリリースで利用可能であった一部の機能が非推奨になるか、または削除されました。

非推奨の機能は依然として OpenShift Container Logging に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

1.47.4.1. 従来の Fluentd および従来の syslog メソッドを使用したログの転送は削除されました

OpenShift Logging 5.3 では、ログを Syslog および Fluentd に転送する従来の方法が削除されています。バグ修正とサポートは、OpenShift Logging5.2 ライフサイクルの終了まで提供されます。その後は、新たな機能拡張は行われません。

代わりに、次にリリースされるレガシー以外のメソッドを使用してください。

1.47.4.2. 従来の転送方法の設定メカニズムは削除されました

OpenShift Logging 5.3 では、ログ転送のレガシー設定メカニズムが削除されました。レガシー Fluentd メソッドとレガシー Syslog メソッドを使用してログを転送できません。代わりに、標準のログ転送方法を使用してください。

1.47.5. CVE

例1.14 クリックして CVE を展開

1.48. Logging 5.2.13

このリリースには、RHSA-2022:5909-OpenShift Logging バグ修正リリース 5.2.13 が含まれます。

1.48.1. バグ修正

1.48.2. CVE

1.49. Logging 5.2.12

本リリースには、RHBA-2022:5558-OpenShift Logging バグ修正リリース 5.2.12 が含まれます。

1.49.1. バグ修正

なし。

1.49.2. CVE

1.50. Logging 5.2.11

本リリースには、RHBA-2022:5012-OpenShift Logging バグ修正リリース 5.2.11 が含まれます。

1.50.1. バグ修正

  • この更新の前は、CloudWatch 転送を実行するように設定されたクラスターが、拒否されたログファイルを一時ストレージに書き込んでいたため、時間の経過とともにクラスターが不安定になりました。今回の更新により、CloudWatch のチャンクバックアップが無効になり、問題が解決されました。(LOG-2635)

1.50.2. CVE

1.51. OpenShift Logging 5.2.10

このリリースには、OpenShift Logging バグ修正リリース 5.2.10 が含まれています

1.51.1. バグ修正

  • この更新の前では、一部のログフォワーダー出力は同じタイムスタンプでログを並べ替えることができました。この更新により、タイムスタンプが一致するエントリーを注文するためのシーケンス番号がログレコードに追加されました。(LOG-2335)
  • この更新の前は、namespace のリストがヘッダーサイズの最大制限に達したため、namespace が多数あるクラスターにより、Elasticsearch はリクエストの処理を停止していました。この更新により、ヘッダーには namespace 名のリストのみが含まれるようになり、問題が解決されました。(LOG-2475)
  • この更新の前は、system:serviceaccount:openshift-monitoring:prometheus-k8s には、clusterrole および clusterrolebinding としてクラスターレベルの特権がありました。この更新により、serviceaccount がロールとロールバインディングを持つ openshift-logging namespace に制限されます。(LOG-2480)
  • この更新の前は、cluster-logging-operator は、クラスタースコープのロールとバインディングを利用して、Prometheus サービスアカウントがメトリックをスクレープするための権限を確立していました。これらの権限は、コンソールインターフェイスを使用して Operator をデプロイする時にだけ作成され、コマンドラインから この Operator をデプロイする場合には欠落していました。これにより、このロールとバインディング namespace のスコープが設定され、問題が修正されます。(LOG-1972)

1.51.2. CVE

1.52. OpenShift Logging 5.2.9

本リリースには、RHBA-2022:1375 OpenShift Logging Bug Fix Release 5.2.9 が含まれます。

1.52.1. バグ修正

  • この更新の前は、キーなしで許容値を定義し、既存の Operator が原因で、Operator はアップグレードを完了できませんでした。今回の更新により、この許容範囲によってアップグレードの完了が妨げられることはなくなりました。(LOG-2304)

1.53. OpenShift Logging 5.2.8

このリリースには、RHSA-2022:0728 OpenShift Logging Bug Fix Release 5.2.8 が含まれます。

1.53.1. バグ修正

  • この更新の前は、OpenShift Container Platform から OpenShift Logging を削除した場合、Web コンソールは引き続き Logging ページへのリンクを表示していました。この更新では、OpenShift Logging を削除またはアンインストールするとそのリンクも削除されます。(LOG-2180)

1.53.2. CVE

例1.19 クリックして CVE を展開

1.54. OpenShift Logging 5.2.7

本リリースには、RHBA-2022:0478 OpenShift Logging Bug Fix Release 5.2.7 が含まれます。

1.54.1. バグ修正

  • 今回の更新以前には、FIPS を有効にして更新した後、Elasticsearch Pod を起動できませんでした。この更新により、Elasticsearch Pod は正常に起動します。(LOG-2000)
  • この更新の前では、永続ボリュームクレーム (PVC) がすでに存在する場合、Elasticsearch は Unable to create PersistentVolumeClaim due to forbidden: exceeded quota: infra-storage-quota. というエラーを生成しました。 この更新により、Elasticsearch は既存の PVC をチェックし、問題を解決します。(LOG-2118)

1.54.2. CVE

1.55. OpenShift Logging 5.2.6

本リリースには、RHSA-2022:0230 OpenShift Logging のバグ修正リリース 5.2.6 が含まれます。

1.55.1. バグ修正

  • 今回の更新以前のリリースにはフィルターの変更が含まれておらず、Fluentd をクラッシュさせる原因となっていました。今回の更新で、欠落していたフィルターが修正されました。(LOG-2104)
  • 今回の更新により、log4j の依存関係が 2.17.1 に変更され、 CVE-2021-44832 が解決されました。(LOG-2101)

1.55.2. CVE

例1.21 クリックして CVE を展開

1.56. OpenShift Logging 5.2.5

本リリースには、RHSA-2022:0043 OpenShift Logging のバグ修正リリース 5.2.5 が含まれます。

1.56.1. バグ修正

  • 今回の更新以前は、Elasticsearch は解析エラーが原因でイベントルーターからのログを拒否していました。今回の更新では、解析エラーを解決するようにデータモデルが変更されています。ただし、その結果、以前のインデックスが原因で Kibana 内で警告またはエラーが発生する可能性があります。kubernetes.event.metadata.resourceVersion フィールドが原因で、既存のインデックスが削除または再インデックスされるまでエラーが発生します。このフィールドが Kibana で使用されていない場合は、エラーメッセージを無視できます。古いインデックスを削除する保持ポリシーがある場合には、このポリシーにより、最終的に古いインデックスが削除されてエラーメッセージを停止します。それ以外の場合は、手動でインデックスを再作成してエラーメッセージを停止します。LOG-2087)

1.56.2. CVE

例1.22 クリックして CVE を展開

1.57. OpenShift Logging 5.2.4

本リリースには、RHSA-2021:5127 OpenShift Logging のバグ修正リリース 5.2.4 が含まれます。

1.57.1. バグ修正

  • 今回の更新以前は、syslog 経由で送信されたレコードは、ルビーハッシュエンコーディングのキーと値のペアをシリアル化して⇒文字を含め、タブを #11 に置き換えていました。今回の更新では、メッセージが適切な JSON として正しくシリアル化されます。(LOG-1775)
  • 今回の更新以前は、Elasticsearch Prometheus エクスポータープラグインは、Elasticsearch ノードのパフォーマンスに影響を与える高コストのクエリーを使用してインデックスレベルのメトリックをコンパイルしていました。この更新で、パフォーマンスを向上させる、低コストのクエリーが実装されています。(LOG-1970)
  • 今回の更新以前は、ログ転送が複数の出力で設定されている場合に、Elasticsearch がメッセージを拒否することがありました。これは、出力の 1 つを設定すると、メッセージの内容が 1 つのメッセージに変更されたために発生しました。今回の更新で、ログ転送は出力ごとにメッセージを複製するようになり、出力固有の処理が他の出力に影響を与えることはありません。(LOG-1824)

1.57.2. CVE

1.58. OpenShift Logging 5.2.3

本リリースには、RHSA-2021:4032 OpenShift Logging のバグ修正リリース 5.2.3 が含まれます。

1.58.1. バグ修正

  • 今回の更新以前は、一部のアラートに namespace ラベルが含まれていませんでした。このようにラベルが省略されていると、OpenShift Container Platform でアラートルールを作成するための OpenShift Monitoring Team のガイドラインに準拠しません。今回の更新では、Elasticsearch Operator のすべてのアラートに namespace ラベルが含まれ、OpenShift Container Platform でアラートルールを作成するための全ガイドラインに準拠します。(LOG-1857)
  • 今回の更新以前では、1 つ前のリリースで発生したリグレッションが原因で、JSON メッセージの解析が意図的に無効にされていました。今回の更新により、JSON 解析が再度有効になりました。また、解析された JSON メッセージの level フィールドをもとに、または正規表現を使用してメッセージフィールドから一致を抽出することで、ログエントリー level を設定します。(LOG-1759)

1.58.2. CVE

1.59. OpenShift Logging 5.2.2

本リリースには、RHBA-2021:3747 OpenShift Logging のバグ修正リリース 5.2.2 が含まれます。

1.59.1. バグ修正

  • 今回の更新以前では、 Cluster Logging カスタムリソース (CR) は、必要なバッファースペースが使用できない場合でも、 total Limit Size フィールドの値を Fluentdtotal_limit_size フィールドに適用していました。今回の更新により、CR は 2 つの totalLimitSize または 'default'値の小さい方を total_limit_size フィールドに適用し、問題が解決されました (LOG-1738)。
  • 今回の更新以前は、1 つ前のリリース設定で発生したリグレッションが原因で、コレクターはシャットダウン前にバッファーされたメッセージをフラッシュしてコレクター Pod の終了と再起動を遅らせていました。今回の更新で、fluentd はシャットダウン時にバッファーをフラッシュしなくなり、問題が解決しました。(LOG-1739)
  • 今回の更新以前は、バンドルマニフェストの問題が原因で、OpenShift Container Platform 4.9 の OLM を使用して Elasticsearch Operator をインストールできませんでした。今回の更新では、バンドルマニフェストが修正され、4.9 でインストールとアップグレードが再度可能になりました。(LOG-1780)

1.59.2. CVE

1.60. OpenShift Logging 5.2.1

本リリースには、RHBA-2021:3550 OpenShift Logging のバグ修正リリース 5.2.1 が含まれます。

1.60.1. バグ修正

  • 今回の更新以前は、リリースパイプラインスクリプトの問題が原因で、 olm.skip Range フィールドの値が、現在のリリース番号を反映するのではなく、 5.2.0 のまま変更されていませんでした。今回の更新 Deha、リリース番号の変更時にこのフィールドの値を更新するようにパイプラインスクリプトが修正されてます。(LOG-1743)

1.60.2. CVE

(なし)

1.61. OpenShift Logging 5.2.0

本リリースには、RHBA-2021:3393 OpenShift Logging のバグ修正リリース 5.2.0 が含まれます。

1.61.1. 新機能および機能拡張

  • 今回の更新では、アプリケーションおよびインフラストラクチャーを監視する Amazon CloudWatch にログデータを転送できるようになりました。詳細は、Forwarding logs to Amazon CloudWatch を参照してください。(LOG-1173)
  • 今回の更新では、Loki (ログデータを水平方向にスケーラブルで可用性の高いマルチテナントログ集約システム) に転送できます。詳細は、Forwarding logs to Loki を参照してください。(LOG-684)
  • 今回の更新では、Fluentd 転送プロトコルを使用して TLS で暗号化された接続でログデータを転送した場合に、パスワードで暗号化された秘密鍵ファイルを使用して、クラスターログフォワーダー設定でパスフレーズを指定できるようになりました。詳細は、Forwarding logs using the Fluentd forward protocol を参照してください。(LOG-1525)
  • 今回の機能拡張により、ユーザー名とパスワードを使用して外部 Elasticsearch インスタンスへのログ転送接続を認証できるようになりました。たとえば、サードパーティーが Elasticsearch インスタンスを操作するため、相互 TLS (mTLS) を使用できない場合に、HTTP または HTTPS を使用してユーザー名とパスワードを含むシークレットを設定できます。詳細は、Forwarding logs to an external Elasticsearch instance を参照してください。(LOG-1022)
  • 今回の更新では、OVN ネットワークポリシー監査ログを収集し、ロギングサーバーに転送できるようになりました。(LOG-1526)

  • デフォルトで、OpenShift Container Platform 4.5 で導入されたデータモデルは、複数の異なる namespace からのログを 1 つの共通のインデックスに送ります。今回の変更により、ログを最も多く生成した namespace を確認することが難しくなります。

    本リリースは namespace メトリクスを OpenShift Container Platform コンソールの Logging ダッシュボードに追加します。これらのメトリクスを使用すると、ログを生成する namespace、および指定のタイムスタンプで各 namespace が生成するログ数を確認できます。

    これらのメトリクスを表示するには、OpenShift Container Platform Web コンソールで Administrator パースペクティブを開き、Observe → Dashboards → Logging/Elasticsearch に移動します。(LOG-1680)

  • 現在のリリース、OpenShift Logging 5.2 は 2 つの新規メトリクスを有効にします。指定のタイムスタンプまたは期間については、個別のコンテナーで生成またはログに記録された合計ログと、コレクターで収集される合計ログを表示できます。これらのメトリクスには namespace、Pod、およびコンテナー名でラベルが付けられるため、各 namespace および Pod が収集および生成されるログの数を確認できます。(LOG-1213)

1.61.2. バグ修正

  • 今回の更新以前は、OpenShift Elasticsearch Operator がインデックス管理 cron ジョブの作成時に、 POLICY_MAPPING 環境変数を 2 回追加したことが原因で apiserver が重複を報告していました。今回の更新では、問題が修正され、POLICY_MAPPING 環境変数が cronjob ごとに 1 回だけ設定され、apiserver で重複が報告されなくなりました。(LOG-1130)
  • 今回の更新以前は、Elasticsearch クラスターを一時停止してノード 0 個にしても、インデックス管理 cron ジョブは一時停止されなかったため、cron ジョブのバックオフが最大になりました。さらに Elasticsearch クラスターの一時停止を解除した後に、バックオフが最大限に達したことが原因で、これらの cron ジョブは停止したままでした。今回の更新プログラムは、cron ジョブとクラスターを一時停止することで問題を解決します。(LOG-1268)
  • 今回の更新以前は、OpenShift Container Platform コンソールのロギングダッシュボードで、上位 10 のログ生成コンテナーのリストに chart namespace のラベルがなく、誤ったメトリック名 fluentd_input_status_total_bytes_logged が提供されていました。今回の更新では、チャートには namespace ラベルと正しいメトリック名 log_logged_bytes_total が表示されます。(LOG-1271)
  • 今回の更新以前は、インデックス管理 cronjob がエラーで終了した場合に、エラー終了コードが報告されず、そのジョブのステータスが complete と報告されていました。 今回の更新では、エラーで終了するインデックス管理 cron ジョブのエラー終了コードを報告することで問題を解決します。(LOG-1273)
  • priorityclasses.v1beta1.scheduling.k8s.io は 1.22 で削除され、 priorityclasses.v1.scheduling.k8s.io に置き換えられました ( v1beta1 は v1 に置き換えられました)。今回の更新以前は、 v1beta1 がまだ存在していたため、 priorityclasses に対して APIRemoved In Next Release In Use アラートが生成されていました。今回の更新では、 v1beta1 を v1 に置き換えることで問題を解決し、アラートが生成されなくなりました。(LOG-1385)
  • 以前は、OpenShift Elasticsearch Operator と Red Hat OpenShift Logging Operator には、オフライン環境で実行できる Operator の OpenShift Container Platform Web コンソールリストへの表示に必要なアノテーションがありませんでした。今回の更新では、 operators.openshift.io/Infrastructure-features: '["Disconnected"]'アノテーションが上記 2 つの Operator に追加され、オフライン環境で実行される Operator リストに表示されるようになります。(LOG-1420)
  • 今回の更新以前は、Red Hat OpenShift Logging Operator Pod は、パフォーマンスが最適化されたシングルノードクラスターで顧客のワークロード向けに予約された CPU コアで、スケジュールされていました。今回の更新では、クラスターロギング Operator Pod は、正しい CPU コアでスケジュールされます。(LOG-1440)
  • 今回の更新以前は、一部のログエントリーで認識されない UTF-8 バイトが含まれていたため、Elasticsearch はメッセージを拒否し、バッファーリングされたペイロード全体をブロックしていました。今回の更新では、拒否されたペイロードが無効なログエントリーを削除して、残りのエントリーを再送信して問題を解決します。(LOG-1499)
  • 今回の更新以前には、kibana-proxy Pod が CrashLoopBackoff 状態になり、Invalid configuration: cookie_secret must be 16, 24, or 32 bytes to create an AES cipher when pass_access_token == true or cookie_refresh != 0, but is 29 bytes. というメッセージをログに記録することがありました。正確な実際のバイト数は異なる場合があります。今回の更新では、Kibana セッションシークレットが正しく生成されるようになり、このエラーが原因で kibana プロキシー Pod が CrashLoopBackoff 状態にならなくなりました。(LOG-1446)
  • 今回の更新以前は、AWS Cloud Watch Fluentd プラグインはすべてのログレベルで AWS API 呼び出しを Fluentd ログに記録し、OpenShift Container Platform ノードリソースを追加で消費していました。今回の更新では、AWS Cloud Watch Fluentd プラグインはデバッグおよびトレースログレベルだけで AWS API 呼び出しをログに記録します。このように、デフォルトの警告ログレベルでは、Fluentd は余分なノードリソースを消費しません。(LOG-1071)
  • 今回の更新以前は、Elasticsearch OpenDistro セキュリティープラグインが原因でユーザーインデックスの移行に失敗していました。今回の更新では、新しいバージョンのプラグインを提供して問題を解決しています。これで、インデックスの移行はエラーなしで進行します。(LOG-1276)
  • 今回の更新以前は、OpenShift Container Platform コンソールのロギングダッシュボードで、上位 10 個のログ生成コンテナーのリストにデータポイントがありませんでした。今回の更新では、問題が解決され、ダッシュボードにすべてのデータポイントが表示されます。(LOG-1353)
  • 今回の更新以前は、 chunkLimitSize と totalLimitSize の値を調整して Fluentd ログフォワーダーのパフォーマンスを調整していた場合に、Setting queued_chunks_limit_size for each buffer to のメッセージにあるように、値が低すぎることが報告されます。今回の更新ではこの問題が修正され、このメッセージが正しい値を報告するようになっています。(LOG-1411)
  • 今回の更新以前は、Kibana OpenDistro セキュリティープラグインが原因でユーザーインデックスの移行に失敗していました。今回の更新では、新しいバージョンのプラグインを提供して問題を解決しています。これで、インデックスの移行はエラーなしで進行します。(LOG-1558)
  • 今回の更新以前は、namespace 入力フィルターを使用すると、その namespace のログが他の入力に表示されませんでした。今回の更新では、ログを受け入れることができるすべての入力に送信されます。(LOG-1570)
  • 今回の更新以前は、viaq/logerr 依存関係のライセンスファイルがないことが原因で、ライセンスのスキャナーが成功せずに中断していました。今回の更新では、 viaq/logerr 依存関係は Apache2.0 でライセンスが提供され、ライセンススキャナーは正常に実行されます。(LOG-1590)
  • 今回の更新以前は、elasticsearch-operator-bundle ビルドパイプラインにある curator5 の誤った brew タグが原因で、ダミーの SHA1 に固定されたイメージがプルされていました。今回の更新では、ビルドパイプラインは curator5 の logging-curator5-rhel8 参照を使用し、インデックス管理 cron ジョブが registry.redhat.io から正しいイメージをプルできるようにします。(LOG-1624)
  • 今回の更新以前は、Service Account 権限の問題により、no permissions for [indices:admin/aliases/get] などのエラーが発生していました。今回の更新では、権限が修正されて問題が解決されています。(LOG-1657)
  • 今回の更新以前は、Red Hat OpenShift Logging Operator のカスタムリソース定義 (CRD) に Loki 出力タイプがないため、アドミッションコントローラーが ClusterLogForwarder カスタムリソースオブジェクトを拒否していました。今回の更新では、CRD に出力タイプとして Loki が含まれるため、管理者は、ログを Loki サーバーに送信するように ClusterLogForwarder を設定できます。(LOG-1683)
  • 今回の更新以前は、OpenShift Elasticsearch Operator で serviceaccounts が調整され、シークレットを含むサードパーティーが所有するフィールドが上書きされていました。この問題が原因で、シークレットが頻繁に再作成されるため、メモリーと CPU の使用率が急増しました。今回の更新で問題が解決されました。現在のリリースでは、OpenShift Elasticsearch Operator は、サードパーティーが所有するフィールドを上書きしません。(LOG-1714)
  • 今回の更新以前には、Cluster Logging カスタムリソース (CR) 定義で、flush_interval 値を指定したにも拘らず、flush_mode を interval に設定しなかった場合に、Red Hat OpenShift Logging Operator は Fluentd 設定を生成しました。ただし、Fluentd コレクターは実行時にエラーを生成しました。今回の更新では、Red Hat OpenShift Logging Operator は ClusterLoggingCR 定義を検証して、両方のフィールドが指定されている場合にのみ Fluentd 設定を生成します。(LOG-1723)

1.61.3. 既知の問題

  • ログを外部 Elasticsearch サーバーに転送してから、ユーザー名とパスワードなどのパイプラインシークレットで設定された値を変更する場合に、Fluentd フォワーダーは新規シークレットを読み込むにもかかわらず、以前の値を使用して外部 Elasticsearch サーバーに接続します。この問題は、現在 Red Hat OpenShift Logging Operator がコンテンツの変更についてシークレットを監視しないために発生します。(LOG-1652)

    回避策として、シークレットを変更した場合には、以下を入力して Fluentd Pod を強制的に再デプロイできます。 

    $ oc delete pod -l component=collector

1.61.4. 非推奨および削除された機能

以前のリリースで利用可能であった一部の機能が非推奨になるか、または削除されました。

非推奨の機能は依然として OpenShift Container Logging に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

1.61.5. 従来の Fluentd および従来の syslog メソッドを使用したログの転送が非推奨に

OpenShift Container Platform 4.6 から現バージョンまで、以下のレガシーメソッドを使用したログの転送は非推奨になり、今後のリリースで削除される予定です。

  • レガシー Fluentd メソッドを使用したログの転送
  • レガシー syslog メソッドを使用したログの転送

代わりに、次にリリースされるレガシー以外のメソッドを使用してください。

1.61.6. CVE

第2章 Logging 5.7

2.1. Logging 5.7 リリースノート

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

注記

stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

2.1.1. Logging 5.7.1

このリリースには、OpenShift Logging Bug Fix Release 5.7.1 が含まれています。

2.1.1.1. バグ修正

  • この更新が行われる前は、Cluster Logging Operator Pod ログ内に多数のノイズの多いメッセージが存在するため、ログの可読性が低下し、重要なシステムイベントを識別することが困難になりました。この更新により、Cluster Logging Operator Pod ログ内のノイズの多いメッセージが大幅に削減されることで、この問題が解決されました。(LOG-3482)
  • この更新より前は、カスタムリソースで別の値が使用されている場合でも、API サーバーは CollectorSpec.Type フィールドの値を Vector にリセットしていました。この更新では、CollectorSpec.Type フィールドのデフォルトが削除され、以前の動作が復元されます。(LOG-4086)
  • この更新が行われるまでは、OpenShift Container Platform Web コンソールでログのヒストグラムをクリックしてドラッグしても時間範囲を選択できませんでした。今回の更新により、クリックとドラッグを使用して時間範囲を正常に選択できるようになりました。(LOG-4501)
  • この更新前は、OpenShift Container Platform Web コンソールで Show Resources リンクをクリックしても何の効果もありませんでした。この更新では、ログエントリーごとにリソースの表示を切り替えるリソースの表示リンクの機能を修正することで、この問題が解決されました。(LOG-3218)

2.1.1.2. CVE

2.1.2. Logging 5.7.0

このリリースには、OpenShift Logging Bug Fix Release 5.7.0 が含まれています。

2.1.2.1. 機能拡張

今回の更新により、ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようになりました。

ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、ClusterLogForwarder カスタムリソース (CR) に、値が true の detectMultilineErrors フィールドが含まれていることを確認します。

2.1.2.2. 既知の問題

なし。

2.1.2.3. バグ修正

  • 今回の更新以前は、LokiStack の Gateway コンポーネントの nodeSelector 属性は、ノードのスケジューリングに影響を与えませんでした。今回の更新により、nodeSelector 属性が想定どおりに機能するようになりました。(LOG-3713)

2.1.2.4. CVE

2.2. Logging 5.7 の使用

ロギングデプロイメントプロセスの概要は、参照しやすいように提供されています。完全なドキュメントに代わるものではありません。新規インストールの場合は、Vector と LokiStack を推奨します。

注記

Logging バージョン 5.5 の時点で、Fluentd または Vector コレクター実装から選択するオプション、およびログストアとして Elasticsearch または LokiStack を選択するオプションがあります。ログのドキュメントは、これらの基本的なコンポーネントの変更を反映するために更新中です。

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

前提条件

  • ログストアの設定: Elasticsearch または LokiStack
  • コレクターの実装設定: Fluentd または Vector
  • ログ転送出力の認証情報
注記

Logging バージョン 5.4.3 の時点で、OpenShift Elasticsearch Operator は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

  1. 使用するログストアの Operator をインストールします。

    • Elasticsearch の場合は、OpenShift Elasticsearch Operator をインストールします。

    • LokiStack の場合は、Loki Operator をインストールします。

      注記

      Loki Operator をインストールしている場合は、LokiStack カスタムリソース (CR) インスタンスも作成します。

  2. Red Hat OpenShift Logging Operator をインストールします。

  3. ClusterLogging CR インスタンスを作成します。

    • コレクターの実装を選択します。

2.3. ロギングアーキテクチャーについて

ロギングサブシステムは、次の論理コンポーネントで設定されています。

  • Collector - 各ノードからコンテナーログデータを読み取り、ログデータを設定済みの出力に転送します。
  • Store - 分析用のログデータを保存します。フォワーダーのデフォルト出力。
  • Visualization - 保存されたログを検索、クエリー、および表示するためのグラフィカルインターフェイス。

これらのコンポーネントは、Operator とカスタムリソース (CR) YAML ファイルによって管理されます。

Red Hat OpenShift のロギングサブシステムは、コンテナーログとノードログを収集します。これらは次のタイプに分類されます。

  • application - 非インフラストラクチャーコンテナーによって生成されたコンテナーログ。
  • infrastructure - namespace kube-* および openshift-\* からのコンテナーログ、および journald からのノードログ。
  • audit - 有効な場合は、auditd、kube-apiserver、openshift-apiserver、および ovn からのログ。

ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットです。システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。

コンテナーログは、クラスターで実行されている Pod で実行されているコンテナーによって生成されます。各コンテナーは個別のログストリームを生成します。コレクターは、これらのソースからログを収集し、ClusterLogForwarder カスタムリソースで設定されているように、それらを内部または外部に転送します。

2.3.1. ロギングのサポートに関する考慮事項

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。このドキュメントで説明されている以外の設定を使用すると、Operator が相違点を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。

注記

OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。マネージド外の OpenShift ロギング環境はサポートされておらず、OpenShift ロギングを Managed に戻すまで更新を受け取りません。

以下の変更は明示的にサポートされていません。

  • ドキュメントで指定されていない namespace へのロギングのデプロイ。
  • OpenShift Container Platform へのカスタム Elasticsearch、Kibana、Fluentd、または Loki インスタンスのインストール。
  • Kibana カスタムリソース (CR) または Elasticsearch CR への変更。
  • ドキュメントで指定されていないシークレットまたは config map への変更。

Red Hat OpenShift のロギングサブシステムは、アプリケーション、インフラストラクチャー、および監査ログの独自のコレクターおよびノーマライザーです。これは、サポートされているさまざまなシステムにログを転送するために使用することを目的としています。

Red Hat OpenShift のロギングサブシステムは次のとおりではありません。

  • 大規模なログ収集システム
  • セキュリティー情報およびイベント監視 (SIEM) に準拠
  • 履歴または長期のログの保持または保管
  • 保証されたログシンク
  • 安全なストレージ - 監査ログはデフォルトでは保存されません

表2.1 Logging 5.7 の出力

出力プロトコルテストで使用FluentdVector

Cloudwatch

REST over HTTP(S)

 

✓

✓

Elasticsearch v6

 

v6.8.1

✓

✓

Elasticsearch v7

 

v7.12.2、7.17.7

✓

✓

Elasticsearch v8

 

v8.4.3

✓

✓

Fluent Forward

Fluentd forward v1

Fluentd 1.14.6、Logstash 7.10.1

✓

 

Google Cloud Logging

   

✓

HTTP

HTTP 1.1

Fluentd 1.14.6、Vector 0.21

✓

✓

Kafka

Kafka 0.11

Kafka 2.4.1、2.7.0、3.3.1

✓

✓

Loki

REST over HTTP(S)

Loki 2.3.0、2.7

✓

✓

Splunk

HEC

v8.2.9、9.0.0

 

✓

Syslog

RFC3164, RFC5424

Rsyslog 8.37.0-9.el7

✓

✓

2.4. ロギングデプロイメントの設定

各 Operator によって実装されたカスタムリソース (CR) YAML ファイルを使用して、ロギングサブシステムのデプロイメントを設定できます。

Red Hat Openshift Logging Operator:

  • ClusterLogging (CL) - コレクターとフォワーダーをデプロイします。現在、どちらも各ノードで実行されているデーモンセットによって実装されています。
  • ClusterLogForwarder (CLF)- ユーザー設定ごとにログを転送するためのコレクター設定を生成します。

Loki Operator:

  • LokiStack - Loki クラスターをログストアとして制御し、OpenShift Container Platform 認証統合を使用して Web プロキシーを制御して、マルチテナンシーを強制します。

OpenShift Elasticsearch Operator:

注記

これらの CR は ClusterLogging Operator によって生成および管理され、手動で変更すると必ず Operator によって上書きされます。

  • Elasticsearch - Elasticsearch インスタンスをデフォルトのログストアとして設定し、デプロイします。
  • Kibana - ログの検索、クエリー、表示を実行するために Kibana インスタンスを設定し、デプロイします。

Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。このドキュメントで説明されている以外の設定を使用すると、Operator が相違点を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。

注記

OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。マネージド外の OpenShift ロギング環境はサポートされておらず、OpenShift ロギングを Managed に戻すまで更新を受け取りません。

2.4.1. Loki でストリームベースの保持を有効にする

Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

  1. ストリームベースの保持を有効にするには、LokiStack カスタムリソース (CR) を作成または編集します。 
oc create -f <file-name>.yaml
  1. 以下の例を参照して、LokiStack CR を設定できます。

グローバルなストリームベースの保持の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: standard
  tenants:
    mode: openshift-logging

1
すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
2
このブロックが CR に追加されると、クラスターで保持が有効になります。
3
ログストリームの定義に使用される LogQL クエリー が含まれています。

テナントごとのストリームベースの保持の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: standard
  tenants:
    mode: openshift-logging

1
テナントごとの保持ポリシーを設定します。有効なテナントタイプは、application、audit、および infrastructure です。
2
ログストリームの定義に使用される LogQL クエリー が含まれています。
  1. 次に、設定を適用します。 
oc apply -f <file-name>.yaml
注記

これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。

2.4.2. 複数行の例外検出の有効化

コンテナーログの複数行のエラー検出を有効にします。

警告

この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。

ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。

Java 例外の例

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

  • ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、ClusterLogForwarder カスタムリソース (CR) に、値が true の detectMultilineErrors フィールドが含まれていることを確認します。

ClusterLogForwarder CR の例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true

2.4.2.1. 詳細

ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。

表2.2 各コレクターでサポートされている言語:

言語FluentdVector

Java

✓

✓

JS

✓

✓

Ruby

✓

✓

Python

✓

✓

golang

✓

✓

PHP

✓

 

Dart

✓

✓

2.4.2.2. トラブルシューティング

有効にすると、コレクター設定には detect_exceptions タイプの新しいセクションが含まれます。

vector 設定セクションの例

[transforms.detect_exceptions_app-logs]
 type = "detect_exceptions"
 inputs = ["application"]
 languages = ["All"]
 group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"]
 expire_after_ms = 2000
 multiline_flush_interval_ms = 1000

fluentd 設定セクションの例

<label @MULTILINE_APP_LOGS>
  <match kubernetes.**>
    @type detect_exceptions
    remove_tag_prefix 'kubernetes'
    message message
    force_line_breaks true
    multiline_flush_interval .2
  </match>
</label>

2.5. ロギングデプロイメントの管理

2.5.1. Web コンソールを使用した Red Hat OpenShift Logging Operator のデプロイ

OpenShift Container Platform Web コンソールを使用して、Red Hat OpenShift Logging Operator をデプロイできます。

前提条件

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

手順

OpenShift Container Platform Web コンソールを使用して、Red Hat OpenShift Logging Operator をデプロイするには、以下を実行します。

  1. Red Hat OpenShift Logging Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
    2. Filter by keyword フィールドに Logging と入力します。
    3. 利用可能な Operator の一覧から Red Hat OpenShift Logging を選択し、Install をクリックします。

    4. Update Channel として stable または stable-5.y を選択します。

      注記

      stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

    5. Installation Mode で A specific namespace on the cluster が選択されていることを確認します。
    6. Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。
    7. Enable Operator recommended cluster monitoring on this Namespace を選択します。

    8. Update approval のオプションを選択します。

      • Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
      • Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
    9. Console プラグインの Enable または Disable を選択します。
    10. Install をクリックします。

  2. Operators → Installed Operators ページに切り替えて、Red Hat OpenShift Logging Operator がインストールされていることを確認します。

    1. Red Hat OpenShift Logging が Status が Succeeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。

  3. ClusterLogging インスタンスを作成します。

    注記

    Web コンソールのフォームビューには、使用可能なすべてのオプションが含まれているわけではありません。セットアップを完了するには、YAML ビュー を推奨します。

    1. collection セクションで、コレクターの実装を選択します。

      注記

      Logging バージョン 5.6 の時点で、Fluentd は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Fluentd の代わりに、Vector を使用できます。

    2. logStore セクションで、タイプを選択します。

      注記

      Logging バージョン 5.4.3 の時点で、OpenShift Elasticsearch Operator は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

    3. Create をクリックします。

2.5.2. Web コンソールを使用した Loki Operator のデプロイ

OpenShift Container Platform コンソールを使用して Loki Operator をインストールできます。

前提条件

  • 対応ログストア (AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation)

手順

OpenShift Container PlatformWeb コンソールを使用して Loki Operator をインストールするには:

  1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。

  2. Filter by keyword フィールドに Loki と入力します。

    1. 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。

  3. Update Channel として stable または stable-5.y を選択します。

    注記

    stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

  4. Installation Mode で All namespaces on the cluster が選択されていることを確認します。
  5. openshift-operators-redhat が Installed Namespace で選択されていることを確認します。

  6. Enable Operator recommended cluster monitoring on this Namespace を選択します。

    このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニターリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

  7. Update approval のオプションを選択します。

    • Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
    • Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
  8. Install をクリックします。

  9. Operators → Installed Operators ページに切り替えて、LokiOperator がインストールされていることを確認します。

    1. LokiOperator の全プロジェクトの Status が Succeeded として表示されているようにします。

  10. access_key_id および access_key_secret フィールドを使用して、認証情報を指定し、bucketnames、endpoint、および region を指定して、オブジェクトストレージの場所を定義する Secret YAML ファイルを作成します。次の例では、AWS が使用されています。 

    apiVersion: v1
kind: Secret
metadata:
  name: logging-loki-s3
  namespace: openshift-logging
stringData:
  access_key_id: AKIAIOSFODNN7EXAMPLE
  access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  bucketnames: s3-bucket-name
  endpoint: https://s3.eu-central-1.amazonaws.com
  region: eu-central-1

  11. Details タブの LokiStack の下にある Create instance を選択します。次に、YAML view を選択します。次のテンプレートに貼り付け、必要に応じて値を置き換えます。 

      apiVersion: loki.grafana.com/v1
  kind: LokiStack
  metadata:
    name: logging-loki 1
    namespace: openshift-logging
  spec:
    size: 1x.small 2
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
      secret:
        name: logging-loki-s3 3
        type: s3 4
    storageClassName: <storage_class_name> 5
    tenants:
      mode: openshift-logging
    1
    名前は、logging-loki にする必要があります。
    2
    Loki のデプロイメントサイズを選択します。
    3
    ログストレージに使用するシークレットを定義します。
    4
    対応するストレージタイプを定義します。
    5
    一時ストレージ用の既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses で一覧表示できます。

    1. 設定を適用します。 

      oc apply -f logging-loki.yaml

  12. ClusterLogging CR を作成または編集します。 

      apiVersion: logging.openshift.io/v1
  kind: ClusterLogging
  metadata:
    name: instance
    namespace: openshift-logging
  spec:
    managementState: Managed
    logStore:
      type: lokistack
      lokistack:
        name: logging-loki
      collection:
        type: vector

    1. 設定を適用します。 

      oc apply -f cr-lokistack.yaml

2.5.3. CLI を使用した OperatorHub からのインストール

OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。oc コマンドを使用して、Subscription オブジェクトを作成または更新します。

前提条件

  • cluster-admin パーミッションを持つアカウンを使用して OpenShift Container Platform クラスターにアクセスできる。
  • oc コマンドをローカルシステムにインストールする。

手順

  1. OperatorHub からクラスターで利用できる Operator の一覧を表示します。 

    $ oc get packagemanifests -n openshift-marketplace

    出力例

    NAME                               CATALOG               AGE
3scale-operator                    Red Hat Operators     91m
advanced-cluster-management        Red Hat Operators     91m
amq7-cert-manager                  Red Hat Operators     91m
...
couchbase-enterprise-certified     Certified Operators   91m
crunchy-postgres-operator          Certified Operators   91m
mongodb-enterprise                 Certified Operators   91m
...
etcd                               Community Operators   91m
jaeger                             Community Operators   91m
kubefed                            Community Operators   91m
...

    必要な Operator のカタログをメモします。

  2. 必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。 

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace

  3. OperatorGroup で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。

    Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (AllNamespaces または SingleNamespace モードのいずれか)。インストールする Operator が AllNamespaces を使用する場合、 openshift-operators namespace には適切な Operator グループがすでに配置されます。

    ただし、Operator が SingleNamespace モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。

    注記

    この手順の Web コンソールバージョンでは、SingleNamespace モードを選択する際に、OperatorGroup および Subscription オブジェクトの作成を背後で自動的に処理します。

    1. OperatorGroup オブジェクト YAML ファイルを作成します (例: operatorgroup.yaml)。

      OperatorGroup オブジェクトのサンプル

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: <operatorgroup_name>
  namespace: <namespace>
spec:
  targetNamespaces:
  - <namespace>

    2. OperatorGroup オブジェクトを作成します。 

      $ oc apply -f operatorgroup.yaml

  4. Subscription オブジェクトの YAML ファイルを作成し、namespace を Operator にサブスクライブします (例: sub.yaml)。

    Subscription オブジェクトの例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: openshift-operators 1
spec:
  channel: <channel_name> 2
  name: <operator_name> 3
  source: redhat-operators 4
  sourceNamespace: openshift-marketplace 5
  config:
    env: 6
    - name: ARGS
      value: "-v=10"
    envFrom: 7
    - secretRef:
        name: license-secret
    volumes: 8
    - name: <volume_name>
      configMap:
        name: <configmap_name>
    volumeMounts: 9
    - mountPath: <directory_name>
      name: <volume_name>
    tolerations: 10
    - operator: "Exists"
    resources: 11
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    nodeSelector: 12
      foo: bar

    1
    AllNamespaces インストールモードの使用については、openshift-operators namespace を指定します。それ以外の場合は、SingleNamespace インストールモードの使用について関連する単一の namespace を指定します。
    2
    サブスクライブするチャネルの名前。
    3
    サブスクライブする Operator の名前。
    4
    Operator を提供するカタログソースの名前。
    5
    カタログソースの namespace。デフォルトの OperatorHub カタログソースには openshift-marketplace を使用します。
    6
    env パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要がある環境変数の一覧を定義します。
    7
    envFrom パラメーターは、コンテナーの環境変数に反映するためのソースの一覧を定義します。
    8
    volumes パラメーターは、OLM によって作成される Pod に存在する必要があるボリュームの一覧を定義します。
    9
    volumeMounts パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要があるボリュームマウントの一覧を定義します。volumeMount が存在しない ボリューム を参照する場合、OLM は Operator のデプロイに失敗します。
    10
    tolerations パラメーターは、OLM によって作成される Pod の容認の一覧を定義します。
    11
    resources パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。
    12
    nodeSelector パラメーターは、OLM によって作成される Pod の ノードセレクター を定義します。

  5. Subscription オブジェクトを作成します。 

    $ oc apply -f sub.yaml

    この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

2.5.4. Web コンソールの使用によるクラスターからの Operator の削除

クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできる。

手順

  1. Operators → Installed Operators ページに移動します。
  2. スクロールするか、またはキーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。

  3. Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。

    Uninstall Operator? ダイアログボックスが表示されます。

  4. Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。

    注記

    このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

2.5.5. CLI の使用によるクラスターからの Operator の削除

クラスター管理者は CLI を使用して、選択した namespace からインストールされた Operator を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • oc コマンドがワークステーションにインストールされていること。

手順

  1. サブスクライブされた Operator (例: jaeger) の現行バージョンを currentCSV フィールドで確認します。 

    $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

    出力例

      currentCSV: jaeger-operator.v1.8.2

  2. サブスクリプション (例: jaeger) を削除します。 

    $ oc delete subscription jaeger -n openshift-operators

    出力例

    subscription.operators.coreos.com "jaeger" deleted

  3. 直前の手順で currentCSV 値を使用し、ターゲット namespace の Operator の CSV を削除します。 

    $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

    出力例

    clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

第3章 Logging 5.6

3.1. Logging 5.6 リリースノート

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

注記

stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

3.1.1. Logging 5.6.6

このリリースには、OpenShift Logging Bug Fix Release 5.6.6 が含まれています。

3.1.1.1. バグ修正

  • この更新が行われるまでは、ペイロード内のキーに一致する Kafka 出力トピックに書き込むように ClusterLogForwarder カスタムリソースを設定すると、エラーによりメッセージのドロップが発生していました。今回の更新では、Fluentd のバッファー名の前にアンダースコアを付けることで問題が解決しました。(LOG-3458)
  • この更新が行われるまでは、inode が再利用され、同じ inode を持つ複数のエントリーが存在する場合に、Fluentd でウォッチの早期終了が発生していました。この更新により、Fluentd 位置ファイル内のウォッチが早期に終了する問題が解決しました。(LOG-3629)
  • この更新が行われるまでは、Fluentd による JavaScript クライアントの複数行例外の検出に失敗し、結果として例外が複数行として出力されていました。今回の更新により、例外が 1 行で出力されるようになり、問題が解決されました。(LOG-3761)
  • この更新が行われるまでは、Red Hat Openshift Logging Operator バージョン 4.6 からバージョン 5.6 への直接アップグレードが許可されていたため、機能上の問題が発生していました。この更新により、アップグレードは 2 つのバージョン以内である必要があり、問題が解決されました。(LOG-3837)
  • この更新が行われるまでは、Splunk または Google Logging 出力のメトリックは表示されませんでした。この更新では、HTTP エンドポイントのメトリックを送信することで問題が解決されました。(LOG-3932)
  • この更新が行われるまでは、ClusterLogForwarder カスタムリソースが削除されても、コレクター Pod は実行されたままでした。この更新により、ログ転送が有効になっていない場合、コレクター Pod は実行されなくなります。(LOG-4030)
  • この更新が行われるまでは、OpenShift Container Platform Web コンソールでログのヒストグラムをクリックしてドラッグしても時間範囲を選択できませんでした。今回の更新により、クリックとドラッグを使用して時間範囲を正常に選択できるようになりました。(LOG-4101)
  • この更新が行われるまでは、監視ファイルの Fluentd ハッシュ値はログファイルへのパスを使用して生成されていたため、ログローテーション時に一意ではないハッシュが生成されました。今回の更新により、監視ファイルのハッシュ値が inode 番号で作成されるようになり、問題が解決されました。(LOG-3633)
  • この更新前は、OpenShift Container Platform Web コンソールで Show Resources リンクをクリックしても何の効果もありませんでした。この更新では、ログエントリーごとにリソースの表示を切り替える リソースの表示 リンクの機能を修正することで、この問題が解決されました。(LOG-4118)

3.1.1.2. CVE

3.1.2. Logging 5.6.5

このリリースには、OpenShift Logging Bug Fix Release 5.6.5 が含まれています。

3.1.2.1. バグ修正

  • この更新前は、テンプレート定義により Elasticsearch が一部のラベルと namespace_label のインデックスを作成できず、データの取り込みで問題が発生していました。この更新では、ラベル内のドットとスラッシュが修正により置き換えられ、適切な取り込みが保証され、問題が効果的に解決されます。(LOG-3419)
  • この更新より前は、OpenShift Web コンソールのログページが LokiStack への接続に失敗した場合、一般的なエラーメッセージが表示され、追加のコンテキストやトラブルシューティングの提案は提供されませんでした。この更新により、エラーメッセージが強化され、より具体的な詳細とトラブルシューティングの推奨事項が含まれるようになりました。(LOG-3750)
  • この更新より前は、時間範囲形式が検証されていなかったため、カスタム日付範囲を選択するとエラーが発生していました。この更新により、時間形式が検証されるようになり、ユーザーが有効な範囲を選択できるようになりました。無効な時間範囲形式が選択された場合、ユーザーにエラーメッセージが表示されます。(LOG-3583)
  • この更新前は、Loki でログを検索する場合、式の長さが 5120 文字を超えていない場合でも、多くの場合、クエリーは失敗していました。この更新により、クエリー承認ラベルマッチャーが最適化され、問題が解決されました。(LOG-3480)
  • この更新が行われる前は、Loki Operator は、プライベート IP のメンバーリストを使用する場合に、すべてのコンポーネントを見つけるのに十分なメンバーリスト設定を生成できませんでした。今回の更新により、生成された設定にアドバタイズされたポートが確実に含まれるようになり、すべてのコンポーネントを正常に検索できるようになりました。(LOG-4008)

3.1.2.2. CVE

3.1.3. Logging 5.6.4

このリリースには、OpenShift Logging Bug Fix Release 5.6.4 が含まれています。

3.1.3.1. バグ修正

  • この更新の前は、LokiStack がログストアとしてデプロイされたときに、Loki Pod によって生成されたログが収集され、LokiStack に送信されていました。今回の更新により、Loki によって生成されたログは収集から除外され、保存されなくなります。(LOG-3280)
  • この更新の前は、OpenShift Web コンソールのログページのクエリーエディターが空の場合は、ドロップダウンメニューに値が入力されませんでした。今回の更新により、空のクエリーを実行しようとすると、エラーメッセージが表示され、ドロップダウンメニューが期待どおりに入力されるようになりました。(LOG-3454)
  • この更新の前は、tls.insecureSkipVerify オプションが true に設定されている場合は、Cluster Logging Operator が誤った設定を生成していました。その結果、Operator は証明書の検証をスキップしようとすると、データを Elasticsearch に送信できませんでした。今回の更新により、tls.insecureSkipVerify が 有効になっている場合でも、Cluster Logging Operator は正しい TLS 設定を生成します。その結果、証明書の検証をスキップしようとしても、データを Elasticsearch に正常に送信できます。(LOG-3475)
  • この更新の前は、構造化された解析が有効になっていて、メッセージが複数の宛先に転送された場合、それらはディープコピーされませんでした。これにより、構造化されたメッセージを含む一部の受信ログが生成されましたが、その他のログは生成されませんでした。今回の更新により、JSON 解析の前にメッセージをディープコピーするように設定生成が変更されました。その結果、複数の宛先に転送された場合でも、すべての受信メッセージに構造化メッセージが含まれるようになりました。(LOG-3640)
  • この更新の前は、collection フィールドに {} が含まれていると、Operator がクラッシュする可能性がありました。今回の更新により、Operator はこの値を無視するようになり、オペレータは中断することなくスムーズに実行し続けることができます。(LOG-3733)
  • この更新の前は、LokiStack のゲートウェイコンポーネントの nodeSelector 属性は効果がありませんでした。今回の更新により、nodeSelector 属性が期待どおりに機能するようになりました。(LOG-3783)
  • この更新の前は、静的な LokiStack メンバーリストの設定は、プライベート IP ネットワークのみに依存していました。その結果、OpenShift Container Platform クラスター Pod ネットワークがパブリック IP 範囲で設定されている場合、LokiStack Pod がクラッシュループします。今回の更新により、LokiStack 管理者は、メンバーリストの設定に Pod ネットワークを使用するオプションを利用できるようになりました。これにより、問題が解決され、OpenShift Container Platform クラスター Pod ネットワークがパブリック IP 範囲で設定されている場合に、LokiStack Pod がクラッシュループ状態になるのを防ぐことができます。(LOG-3814)
  • この更新の前は、tls.insecureSkipVerify フィールドが true に設定されている場合、Cluster Logging Operator は間違った設定を生成していました。その結果、証明書の検証をスキップしようとすると、Operator は Elasticsearch にデータを送信できませんでした。今回の更新により、tls.insecureSkipVerify が有効になっている場合でも、Operator は正しい TLS 設定を生成します。その結果、証明書の検証をスキップしようとしても、データを Elasticsearch に正常に送信できます。(LOG-3838)
  • この更新の前に、Elasticsearch Operator を使用せずに Cluster Logging Operator (CLO) がインストールされた場合、CLO Pod は Elasticsearch の削除に関連するエラーメッセージを継続的に表示していました。今回の更新により、CLO はエラーメッセージを表示する前に追加のチェックを実行するようになりました。その結果、Elasticsearch Operator が存在しない場合は、Elasticsearch の削除に関連するエラーメッセージが表示されなくなりました。(LOG-3763)

3.1.3.2. CVE

3.1.4. Logging 5.6.3

このリリースには、OpenShift Logging Bug Fix Release 5.6.3 が含まれています。

3.1.4.1. バグ修正

  • 今回の更新の前は、Operator はゲートウェイテナントのシークレット情報を config map に保存していました。今回の更新により、Operator はこの情報をシークレットに保存します。(LOG-3717)
  • 今回の更新の前は、Fluentd コレクターは /var/log/auth-server/audit.log に保存されている OAuth ログインイベントをキャプチャーしませんでした。今回の更新により、Fluentd は、これらの OAuth ログインイベントをキャプチャーし、問題を解決しました。(LOG-3729)

3.1.4.2. CVE

3.1.5. Logging 5.6.2

本リリースには、OpenShift Logging バグ修正リリース 5.6.2 が含まれます。

3.1.5.1. バグ修正

  • この更新の前は、コレクターは systemd ログの優先度に基づいて level フィールドを正しく設定しませんでした。今回の更新により、level フィールドが正しく設定されるようになりました。(LOG-3429)
  • 今回の更新以前は、Operator は OpenShift Container Platform 4.12 以降で非互換性の警告を誤って生成していました。今回の更新により、Operator の OpenShift Container Platform の最大バージョン値が修正され、問題が解決されました。(LOG-3584)
  • 今回の更新以前は、default の出力値で ClusterLogForwarder カスタムリソース (CR) を作成し、エラーを生成しませんでした。今回の更新により、この値が適切に生成されるというエラーの警告が表示されるようになりました。(LOG-3437)
  • この更新の前は、ClusterLogForwarder カスタムリソース (CR) に 1 つの出力が default として設定された複数のパイプラインがある場合、コレクター Pod は再起動していました。今回の更新で、出力検証のロジックが修正され、問題が解決されました。(LOG-3559)
  • この更新の前は、コレクター Pod は作成後に再起動されていました。今回の更新により、デプロイされたコレクターが自動的に再起動しなくなりました。(LOG-3608)
  • 今回の更新以前は、パッチリリースがカタログから以前のバージョンの Operator を削除していました。これにより、古いバージョンをインストールすることができませんでした。今回の更新により、バンドル設定が変更され、同じマイナーバージョンの以前のリリースがカタログに留まるようになりました。(LOG-3635)

3.1.5.2. CVE

3.1.6. Logging 5.6.1

本リリースには、OpenShift Logging バグ修正リリース 5.6.1 が含まれます。

3.1.6.1. バグ修正

  • この更新の前は、保持が有効な場合、コンパクターは、クエリーアとの通信による TLS 証明書エラーを報告していました。今回の更新により、コンパクターとクエリーアが HTTP 経由で誤って通信することがなくなりました。(LOG-3494)
  • この更新の前は、Loki Operator は LokiStack CR のステータスの設定を再試行しないため、ステータス情報が古くなっていました。今回の更新により、Operator は競合時にステータス情報の更新を再試行するようになりました。(LOG-3496)
  • この更新の前は、kube-apiserver-operator Operator が Webhook の有効性を確認したときに、Loki Operator Webhook サーバーが TLS エラーを引き起こしていました。今回の更新により、Loki Operator Webhook PKI は Operator Lifecycle Manager (OLM) によって管理されるようになり、問題が解決されました。(LOG-3510)
  • この更新の前は、ブール式と組み合わせてラベルフィルターを使用した場合、LokiStack ゲートウェイラベルエンフォーサーが有効な LogQL クエリーの解析エラーを生成していました。今回の更新により、LokiStack LogQL の実装がブール式を使用したラベルフィルターをサポートするようになり、問題が解決されました。(LOG-3441)、(LOG-3397)
  • この更新の前は、複数のラベルキーに同じ接頭辞があり、一部のキーにドットが含まれていると、Elasticsearch に書き込まれたレコードで障害が発生していました。今回の更新により、ラベルキーのドットがアンダースコアに置き換えられ、問題が解決されました。(LOG-3463)
  • この更新の前は、OpenShift Container Platform コンソールと logging-view-plugin の間に互換性がないため、Red Hat OpenShift Logging Operator は OpenShift Container Platform 4.10 クラスターで使用できませんでした。今回の更新により、プラグインは OpenShift Container Platform 4.10 管理コンソールと適切に統合されるようになりました。(LOG-3447)
  • この更新の前は、ClusterLogForwarder カスタムリソースの調整で、デフォルトログストアを参照するパイプラインの低下ステータスが誤って報告されていました。今回の更新により、パイプラインが適切に検証されるようになりました (LOG-3477)。

3.1.6.2. CVE

3.1.7. Logging 5.6.0

このリリースには、OpenShift Logging Release 5.6 が含まれています。

3.1.7.1. 非推奨の通知

Logging バージョン 5.6 では、Fluentd は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Fluentd の代わりに、Vector を使用できます。

3.1.7.2. 機能拡張

  • 今回の更新により、Logging は OpenShift Container Platform のクラスター全体の暗号化ポリシーに準拠します。(LOG-895)
  • 今回の更新により、LokiStack カスタムリソースを使用して、テナントごと、ストリームごと、およびグローバルポリシーの保持ポリシーを優先度順に宣言できるようになります。(LOG-2695)
  • 今回の更新により、Splunk がログ転送の出力オプションとして利用できるようになります。(LOG-2913)
  • 今回の更新により、デフォルトコレクターが Fluentd から Vector になります。(LOG-2222)
  • 今回の更新により、Developer ロールは、OpenShift Container Platform 4.11 以降を実行しているクラスターの Log Console Plugin 内で割り当てられているプロジェクトごとのワークロードログにアクセスできます。(LOG-3388)
  • 今回の更新により、任意のソースからのログに、Operator がデプロイされているクラスターの一意識別子であるフィールド openshift.cluster_id が含まれるようになります。clusterID の値は、以下のコマンドで表示できます。(LOG-2715) 
$ oc get clusterversion/version -o jsonpath='{.spec.clusterID}{"\n"}'

3.1.7.3. 既知の問題

  • この更新の前は、複数のラベルキーに同じ接頭辞があり、一部のキーに . が含まれていると、Elasticsearch がログを拒否することがありました。これは、ラベルキーに含まれる . を _ に置き換えることで、Elasticsearch の制限を修正します。この問題の回避策として、エラーの原因となっているラベルを削除するか、namespace をラベルに追加します。(LOG-3463)

3.1.7.4. バグ修正

  • 今回の更新の前は、Kibana カスタムリソースを削除した場合、OpenShift Container Platform Web コンソールは引き続き Kibana へのリンクを表示していました。今回の更新で、Kibana カスタムリソースを削除すると、そのリンクも削除されます。(LOG-2993)
  • この更新の前は、ユーザーはアクセス権を持つ namespace のアプリケーションログを表示できませんでした。今回の更新により、Loki Operator はクラスターロールとクラスターロールバインディングを自動的に作成し、ユーザーがアプリケーションログを読み取れるようにします。(LOG-3072)
  • この更新の前に、LokiStack をデフォルトのログストレージとして使用する場合、Operator は ClusterLogForwarder カスタムリソースで定義されたカスタム出力を削除しました。今回の更新により、Operator は ClusterLogForwarder カスタムリソースの処理時にカスタム出力をデフォルト出力とマージします。(LOG-3090)
  • この更新の前に、CA キーは CA を Loki にマウントするためのボリューム名として使用されていたため、CA キーに非準拠の文字 (ドットなど) が含まれているとエラー状態が発生していました。今回の更新により、ボリューム名が内部文字列に標準化され、問題が解決されました。(LOG-3331)
  • この更新の前は、LokiStack カスタムリソース定義内で設定されたデフォルト値が原因で、1 の ReplicationFactor なしで LokiStack インスタンスを作成できませんでした。今回の更新により、Operator は使用されるサイズの実際の値を設定するようになります。(LOG-3296)
  • この更新の前は、Vector は、JSON 解析が有効になっている場合に、structuredTypeKey または structuredTypeName の値も定義せずにメッセージフィールドを解析していました。今回の更新により、構造化ログを Elasticsearch に書き込むときに、structuredTypeKey または structuredTypeName のいずれかに値が必要になりました。(LOG-3195)
  • この更新の前は、Elasticsearch Operator のシークレット作成コンポーネントが内部シークレットを常に変更していました。今回の更新により、既存のシークレットが適切に処理されるようになりました。(LOG-3161)
  • この更新の前は、Elasticsearch または Kibana デプロイメントのステータスが変更されている間に、Operator がコレクターデーモンセットの削除と再作成のループに入る可能性がありました。今回の更新では、Operator のステータス処理が修正され、問題が解決されました。(LOG-3157)
  • この更新の前は、Kibana の OAuth cookie の有効期限は 24h に固定されていたため、accessTokenInactivityTimeout フィールドが 24h 未満の値に設定されていると、Kibana で 401 エラーが発生していました。今回の更新により、Kibana の OAuth cookie の有効期限が accessTokenInactivityTimeout に同期され、デフォルト値は 24h になります。(LOG-3129)
  • この更新の前は、リソースを調整するための Operator の一般的なパターンとして、取得または更新を試みる前に作成を試みていました。そのため、作成後に一定の HTTP 409 レスポンスが発生していました。今回の更新により、Operator は最初にオブジェクトの取得を試み、オブジェクトが欠落しているか指定されていない場合にのみ作成または更新するようになります。(LOG-2919)
  • この更新の前は、Fluentd の .level フィールドと .structure.level フィールドに異なる値が含まれることがありました。今回の更新により、各フィールドの値が同じになります。(LOG-2819)
  • この更新の前は、Operator は信頼された CA バンドルの作成を待たず、バンドルが更新された後に 2 回目のコレクターデプロイメントを実行していました。今回の更新により、Operator は、コレクターデプロイメントを続行する前に、バンドルが読み込まれたかどうかを確認するために少し待機するようになります。(LOG-2789)
  • この更新の前は、メトリクスを確認するときに Telemetry ログ情報が 2 回表示されていました。今回の更新により、Telemetry ログ情報が想定どおりに表示されます。(LOG-2315)
  • この更新の前は、JSON 解析の追加を有効にした後、Fluentd Pod ログに警告メッセージが含まれていました。今回の更新でにより、その警告メッセージは表示されなくなりました。(LOG-1806)
  • この更新の前は、キャッシュをビルドするために書き込み権限を持つフォルダーを oc が必要とするため、must-gather スクリプトは完了しませんでした。今回の更新により、oc はフォルダーへの書き込み権限を持ち、must-gather スクリプトが正常に完了するようになります。(LOG-3446)
  • この更新の前は、ログコレクター SCC がクラスター上の他の SCC に取って代わられ、コレクターが使用できなくなる可能性がありました。今回の更新により、ログコレクター SCC の優先度が設定され、他の SCC よりも優先されるようになりました。(LOG-3235)
  • この更新の前は、Vector に sequence フィールドはなく、ナノ秒単位の精度の欠落に対処する方法として fluentd に追加されていました。今回の更新により、openshift.sequence フィールドがイベントログに追加されました。(LOG-3106)

3.1.7.5. CVE

3.2. Logging 5.6 を使い始める

ロギングデプロイメントプロセスの概要は、参照しやすいように提供されています。完全なドキュメントに代わるものではありません。新規インストールの場合は、Vector と LokiStack を推奨します。

注記

Logging バージョン 5.5 の時点で、Fluentd または Vector コレクター実装から選択するオプション、およびログストアとして Elasticsearch または LokiStack を選択するオプションがあります。ログのドキュメントは、これらの基本的なコンポーネントの変更を反映するために更新中です。

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

前提条件

  • ログストアの設定: Elasticsearch または LokiStack
  • コレクターの実装設定: Fluentd または Vector
  • ログ転送出力の認証情報
注記

Logging バージョン 5.4.3 の時点で、OpenShift Elasticsearch Operator は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

  1. 使用するログストアの Operator をインストールします。

    • Elasticsearch の場合は、OpenShift Elasticsearch Operator をインストールします。

    • LokiStack の場合は、Loki Operator をインストールします。

      注記

      Loki Operator をインストールしている場合は、LokiStack カスタムリソース (CR) インスタンスも作成します。

  2. Red Hat OpenShift Logging Operator をインストールします。

  3. ClusterLogging CR インスタンスを作成します。

    • コレクターの実装を選択します。

3.3. ロギングアーキテクチャーについて

ロギングサブシステムは、次の論理コンポーネントで設定されています。

  • Collector - 各ノードからコンテナーログデータを読み取り、ログデータを設定済みの出力に転送します。
  • Store - 分析用のログデータを保存します。フォワーダーのデフォルト出力。
  • Visualization - 保存されたログを検索、クエリー、および表示するためのグラフィカルインターフェイス。

これらのコンポーネントは、Operator とカスタムリソース (CR) YAML ファイルによって管理されます。

Red Hat OpenShift のロギングサブシステムは、コンテナーログとノードログを収集します。これらは次のタイプに分類されます。

  • application - 非インフラストラクチャーコンテナーによって生成されたコンテナーログ。
  • infrastructure - namespace kube-* および openshift-\* からのコンテナーログ、および journald からのノードログ。
  • audit - 有効な場合は、auditd、kube-apiserver、openshift-apiserver、および ovn からのログ。

ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットです。システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。

コンテナーログは、クラスターで実行されている Pod で実行されているコンテナーによって生成されます。各コンテナーは個別のログストリームを生成します。コレクターは、これらのソースからログを収集し、ClusterLogForwarder カスタムリソースで設定されているように、それらを内部または外部に転送します。

3.3.1. ロギングのサポートに関する考慮事項

注記

ロギングは、コアの OpenShift Container Platform とは異なるリリースサイクルで、インストール可能なコンポーネントとして提供されます。Red Hat OpenShift Container Platform Life Cycle Policy はリリースの互換性を概説しています。

Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。このドキュメントで説明されている以外の設定を使用すると、Operator が相違点を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。

注記

OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。マネージド外の OpenShift ロギング環境はサポートされておらず、OpenShift ロギングを Managed に戻すまで更新を受け取りません。

以下の変更は明示的にサポートされていません。

  • ドキュメントで指定されていない namespace へのロギングのデプロイ。
  • OpenShift Container Platform へのカスタム Elasticsearch、Kibana、Fluentd、または Loki インスタンスのインストール。
  • Kibana カスタムリソース (CR) または Elasticsearch CR への変更。
  • ドキュメントで指定されていないシークレットまたは config map への変更。

Red Hat OpenShift のロギングサブシステムは、アプリケーション、インフラストラクチャー、および監査ログの独自のコレクターおよびノーマライザーです。これは、サポートされているさまざまなシステムにログを転送するために使用することを目的としています。

Red Hat OpenShift のロギングサブシステムは次のとおりではありません。

  • 大規模なログ収集システム
  • セキュリティー情報およびイベント監視 (SIEM) に準拠
  • 履歴または長期のログの保持または保管
  • 保証されたログシンク
  • 安全なストレージ - 監査ログはデフォルトでは保存されません

3.4. ロギングデプロイメントの設定

各 Operator によって実装されたカスタムリソース (CR) YAML ファイルを使用して、ロギングサブシステムのデプロイメントを設定できます。

Red Hat Openshift Logging Operator:

  • ClusterLogging (CL) - コレクターとフォワーダーをデプロイします。現在、どちらも各ノードで実行されているデーモンセットによって実装されています。
  • ClusterLogForwarder (CLF)- ユーザー設定ごとにログを転送するためのコレクター設定を生成します。

Loki Operator:

  • LokiStack - Loki クラスターをログストアとして制御し、OpenShift Container Platform 認証統合を使用して Web プロキシーを制御して、マルチテナンシーを強制します。

OpenShift Elasticsearch Operator:

注記

これらの CR は ClusterLogging Operator によって生成および管理され、手動で変更すると必ず Operator によって上書きされます。

  • Elasticsearch - Elasticsearch インスタンスをデフォルトのログストアとして設定し、デプロイします。
  • Kibana - ログの検索、クエリー、表示を実行するために Kibana インスタンスを設定し、デプロイします。

Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。このドキュメントで説明されている以外の設定を使用すると、Operator が相違点を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。

注記

OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。マネージド外の OpenShift ロギング環境はサポートされておらず、OpenShift ロギングを Managed に戻すまで更新を受け取りません。

3.4.1. Loki でストリームベースの保持を有効にする

Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

  1. ストリームベースの保持を有効にするには、LokiStack カスタムリソース (CR) を作成または編集します。 
oc create -f <file-name>.yaml
  1. 以下の例を参照して、LokiStack CR を設定できます。

グローバルなストリームベースの保持の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: standard
  tenants:
    mode: openshift-logging

1
すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
2
このブロックが CR に追加されると、クラスターで保持が有効になります。
3
ログストリームの定義に使用される LogQL クエリー が含まれています。

テナントごとのストリームベースの保持の例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Man