1.9. Logging 5.4
以下のアドバイザリーは、ロギング 5.4 に使用できます Logging subsystem for Red Hat OpenShift Release 5.4
1.9.1. テクノロジープレビュー
Vector はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat の実稼働環境におけるサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
1.9.2. Vector について
Vector は、ロギングサブシステムの現在のデフォルトコレクターに代わるテクノロジープレビューとして提供されるログコレクターです。
次の出力がサポートされています。
-
elasticsearch
。外部 Elasticsearch インスタンス。elasticsearch
出力では、TLS 接続を使用できます。 -
kafka
。Kafka ブローカー。kafka
出力は、セキュリティーで保護されていない接続または TLS 接続を使用できます。 -
loki
。Loki: 水平方向にスケーラブルで可用性の高いマルチテナントログ集計システム。
1.9.2.1. Vector の有効化
Vector はデフォルトでは有効になっていません。以下のステップを使用して、OpenShift Container Platform クラスターで Vector を有効にします。
Vector は、FIPS 対応クラスターをサポートしていません。
前提条件
- OpenShift Container Platform: 4.10
- Red Hat OpenShift のロギングサブシステム: 5.4
- FIPS が無効
手順
openshift-logging
プロジェクトでClusterLogging
カスタムリソース (CR) を編集します。$ oc -n openshift-logging edit ClusterLogging instance
-
logging.openshift.io/preview-vector-collector: enabled
アノテーションをClusterLogging
カスタムリソース (CR) に追加します。 -
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.9.3. Loki について
Loki は、水平方向にスケーラブルで可用性の高いマルチテナントログ集約システムであり、現在、ロギングサブシステムのログストアとして Elasticsearch の代替として提供されています。
関連情報
1.9.3.1. Lokistack のデプロイ
OpenShift Container Platform コンソールを使用して LokiOperator をインストールできます。
前提条件
- OpenShift Container Platform: 4.10
- Red Hat OpenShift のロギングサブシステム: 5.4
OpenShift Container PlatformWeb コンソールを使用して LokiOperator をインストールするには:
LokiOperator をインストールします。
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub をクリックします。 - 使用可能な Operator のリストから LokiOperator を選択し、Install をクリックします。
- Installation Mode で、All namespaces on the cluster を選択します。
Installed Namespace で、openshift-operators-redhat を選択します。
openshift-operators-redhat
namespace を指定する必要があります。openshift-operators
namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。Enable operator recommended cluster monitoring on this namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"
ラベルを設定します。クラスターモニターリングがopenshift-operators-redhat
namespace を収集できるように、このオプションを選択する必要があります。Approval Strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
- LokiOperator をインストールしたことを確認します。Operators→ Installed Operators ページにアクセスして、LokiOperator を探します。
- LokiOperator が Status が Succeeded であるすべてのプロジェクトにリストされていることを確認します。
-
OpenShift Container Platform Web コンソールで、Operators
1.9.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)