3.2. Logging 5.5 を使い始める
ロギングデプロイメントプロセスの概要は、参照しやすいように提供されています。完全なドキュメントに代わるものではありません。新規インストールの場合は、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 を使用できます。
使用するログストアの Operator をインストールします。
- Elasticsearch の場合は、OpenShift Elasticsearch Operator をインストールします。
LokiStack の場合は、Loki Operator をインストールします。
注記Loki Operator をインストールしている場合は、
LokiStackカスタムリソース (CR) インスタンスも作成します。
- Red Hat OpenShift Logging Operator をインストールします。
ClusterLoggingCR インスタンスを作成します。コレクターの実装を選択します。
= Understanding logging architecture :experimental: :imagesdir: images :prewrap!: :op-system-first: Red Hat Enterprise Linux CoreOS (RHCOS) :op-system: RHCOS :op-system-lowercase: rhcos :op-system-base: RHEL :op-system-base-full: Red Hat Enterprise Linux (RHEL) :op-system-version: 8.x :tsb-name: Template Service Broker :kebab:
:rh-openstack-first: Red Hat OpenStack Platform (RHOSP) :rh-openstack: RHOSP :ai-full: Assisted Installer :ai-version: 2.3 :cluster-manager-first: Red Hat OpenShift Cluster Manager :cluster-manager: OpenShift Cluster Manager :cluster-manager-url: OpenShift Cluster Manager Hybrid Cloud Console :cluster-manager-url-pull: pull secret from the Red Hat OpenShift Cluster Manager :insights-advisor-url: Insights Advisor :hybrid-console: Red Hat Hybrid Cloud Console :hybrid-console-second: Hybrid Cloud Console :oc-first: OpenShift CLI (oc) :product-registry: OpenShift image registry :rh-storage-first: Red Hat OpenShift Data Foundation :rh-storage: OpenShift Data Foundation :rh-rhacm-first: Red Hat Advanced Cluster Management (RHACM) :rh-rhacm: RHACM :rh-rhacm-version: 2.6 :sandboxed-containers-first: OpenShift sandboxed containers :sandboxed-containers-operator: OpenShift sandboxed containers Operator :sandboxed-containers-version: 1.3 :sandboxed-containers-version-z: 1.3.1 :sandboxed-containers-legacy-version: 1.3.0 :cert-manager-operator: cert-manager Operator for Red Hat OpenShift :secondary-scheduler-operator-full: Secondary Scheduler Operator for Red Hat OpenShift :secondary-scheduler-operator: Secondary Scheduler Operator :rh-virtualization-first: Red Hat Virtualization (RHV) :rh-virtualization: RHV :rh-virtualization-hyper-first: Red Hat Virtualization Hypervisor (RHV-H) :rh-virtualization-hyper: RHV-H :rh-virtualization-engine-name: Manager :velero-domain: velero.io :velero-version: 1.9 :launch:
:mtc-short: MTC :mtc-full: Migration Toolkit for Containers :mtc-version: 1.7 :mtc-version-z: 1.7 :builds-v2title: Builds for Red Hat OpenShift :builds-v2shortname: OpenShift Builds v2 :builds-v1shortname: OpenShift Builds v1 :gitops-title: Red Hat OpenShift GitOps :gitops-shortname: GitOps :gitops-ver: 1.1 :rh-app-icon:
:pipelines-title: Red Hat OpenShift Pipelines :pipelines-shortname: OpenShift Pipelines :pipelines-ver: pipelines-1.10 :tekton-chains: Tekton Chains :tekton-hub: Tekton Hub :pac: Pipelines as Code :odo-title: odo :alibaba: Alibaba Cloud :oke: OpenShift Kubernetes Engine :opp: OpenShift Platform Plus :VirtProductName: OpenShift Virtualization :VirtVersion: 4.11 :KubeVirtVersion: v0.53.2 :HCOVersion: 4.11.5 :delete:
:DTProductName: Red Hat OpenShift distributed tracing :DTShortName: distributed tracing :DTProductVersion: 2.8 :JaegerName: Red Hat OpenShift distributed tracing platform :JaegerShortName: distributed tracing platform :JaegerVersion: 1.42.0 :OTELName: Red Hat OpenShift distributed tracing data collection :OTELShortName: distributed tracing data collection :OTELVersion: 0.74.0 :TempoName: Tempo Operator :TempoShortName: Tempo :TempoVersion: 0.1.0 :logging-title: logging subsystem for Red Hat OpenShift :logging-title-uc: Logging subsystem for Red Hat OpenShift :logging: logging subsystem :logging-uc: Logging subsystem :ServerlessProductName: OpenShift Serverless :ServerlessProductShortName: Serverless :ServerlessOperatorName: OpenShift Serverless Operator :FunctionsProductName: OpenShift Serverless Functions :product-dedicated: Red Hat OpenShift Dedicated :product-rosa: Red Hat OpenShift Service on AWS :SMProductName: Red Hat OpenShift Service Mesh :SMProductShortName: Service Mesh :SMProductVersion: 2.4.2 :MaistraVersion: 2.4 :SMProductVersion1x: 1.1.18.2 :productwinc: Red Hat OpenShift support for Windows Containers :ibmcloudBMProductName: IBM Cloud Bare Metal (Classic) :ibmcloudBMRegProductName: IBM Cloud® Bare Metal (Classic) :ibmpowerProductName: IBM Power :ibmzProductName: IBM Z :rhq-cso: Red Hat Quay Container Security Operator :sno: single-node OpenShift :sno-caps: Single-node OpenShift :cgu-operator-first: Topology Aware Lifecycle Manager (TALM) :cgu-operator-full: Topology Aware Lifecycle Manager :cgu-operator: TALM :redfish-operator: Bare Metal Event Relay :openshift-local-productname: Red Hat OpenShift Local :openshift-dev-spaces-productname: Red Hat OpenShift Dev Spaces :web-terminal-op: Web Terminal Operator :devworkspace-op: DevWorkspace Operator :context: logging-5.5-architecture
ロギングサブシステムは、次の論理コンポーネントで設定されています。
-
Collector- 各ノードからコンテナーログデータを読み取り、ログデータを設定済みの出力に転送します。 -
Store- 分析用のログデータを保存します。フォワーダーのデフォルト出力。 -
Visualization- 保存されたログを検索、クエリー、および表示するためのグラフィカルインターフェイス。
これらのコンポーネントは、Operator とカスタムリソース (CR) YAML ファイルによって管理されます。
Red Hat OpenShift のロギングサブシステムは、コンテナーログとノードログを収集します。これらは次のタイプに分類されます。
-
application- 非インフラストラクチャーコンテナーによって生成されたコンテナーログ。 -
infrastructure- namespacekube-*およびopenshift-\*からのコンテナーログ、およびjournaldからのノードログ。 -
audit- 有効な場合は、auditd、kube-apiserver、openshift-apiserver、およびovnからのログ。
ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットです。システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。
コンテナーログは、クラスターで実行されている Pod で実行されているコンテナーによって生成されます。各コンテナーは個別のログストリームを生成します。コレクターは、これらのソースからログを収集し、ClusterLogForwarder カスタムリソースで設定されているように、それらを内部または外部に転送します。
3.2.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.2.1.1. ロギングデプロイメントの管理
3.2.1.1.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 をデプロイするには、以下を実行します。
Red Hat OpenShift Logging Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドに Logging と入力します。
- 利用可能な Operator の一覧から Red Hat OpenShift Logging を選択し、Install をクリックします。
Update Channel として stable または stable-5.y を選択します。
注記stableチャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルをstable-X(Xはインストールしたログのバージョン) に変更する必要があります。- Installation Mode で A specific namespace on the cluster が選択されていることを確認します。
- Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。
- Enable Operator recommended cluster monitoring on this Namespace を選択します。
Update approval のオプションを選択します。
- Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
- Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
- Console プラグインの Enable または Disable を選択します。
- Install をクリックします。
Operators → Installed Operators ページに切り替えて、Red Hat OpenShift Logging Operator がインストールされていることを確認します。
- Red Hat OpenShift Logging が Status が Succeeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。
ClusterLogging インスタンスを作成します。
注記Web コンソールのフォームビューには、使用可能なすべてのオプションが含まれているわけではありません。セットアップを完了するには、YAML ビュー を推奨します。
collection セクションで、コレクターの実装を選択します。
注記Logging バージョン 5.6 の時点で、Fluentd は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Fluentd の代わりに、Vector を使用できます。
logStore セクションで、タイプを選択します。
注記Logging バージョン 5.4.3 の時点で、OpenShift Elasticsearch Operator は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。
- Create をクリックします。
3.2.1.1.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 をインストールするには:
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
Filter by keyword フィールドに Loki と入力します。
- 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
Update Channel として stable または stable-5.y を選択します。
注記stableチャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルをstable-X(Xはインストールしたログのバージョン) に変更する必要があります。- Installation Mode で All namespaces on the cluster が選択されていることを確認します。
- openshift-operators-redhat が Installed Namespace で選択されていることを確認します。
Enable Operator recommended cluster monitoring on this Namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"ラベルを設定します。クラスターモニタリングがopenshift-operators-redhatnamespace を収集できるように、このオプションを選択する必要があります。Update approval のオプションを選択します。
- Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
- Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
- Install をクリックします。
Operators → Installed Operators ページに切り替えて、LokiOperator がインストールされていることを確認します。
- LokiOperator の全プロジェクトの Status が Succeeded として表示されているようにします。
access_key_idおよびaccess_key_secretフィールドを使用して、認証情報を指定し、bucketnames、endpoint、およびregionを指定して、オブジェクトストレージの場所を定義するSecretYAML ファイルを作成します。次の例では、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
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-loggingClusterLoggingCR を作成または編集します。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設定を適用します。
oc apply -f cr-lokistack.yaml
3.2.1.1.3. CLI を使用した OperatorHub からのインストール
OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。oc コマンドを使用して、Subscription オブジェクトを作成または更新します。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 -
ocコマンドをローカルシステムにインストールする。
手順
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 のカタログをメモします。
必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。
$ oc describe packagemanifests <operator_name> -n openshift-marketplace
OperatorGroupで定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (
AllNamespacesまたはSingleNamespaceモードのいずれか)。インストールする Operator がAllNamespacesを使用する場合、openshift-operatorsnamespace には適切な Operator グループがすでに配置されます。ただし、Operator が
SingleNamespaceモードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。注記この手順の Web コンソールバージョンでは、
SingleNamespaceモードを選択する際に、OperatorGroupおよびSubscriptionオブジェクトの作成を背後で自動的に処理します。OperatorGroupオブジェクト YAML ファイルを作成します (例:operatorgroup.yaml)。OperatorGroupオブジェクトのサンプルapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <namespace> spec: targetNamespaces: - <namespace>
OperatorGroupオブジェクトを作成します。$ oc apply -f operatorgroup.yaml
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-operatorsnamespace を指定します。カスタムグローバル 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 のノードセレクターを定義します。
Subscriptionオブジェクトを作成します。$ oc apply -f sub.yaml
この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
3.2.1.1.4. Web コンソールの使用によるクラスターからの Operator の削除
クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできる。
手順
- Operators → Installed Operators ページに移動します。
- スクロールするか、キーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。
Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。
Uninstall Operator? ダイアログボックスが表示されます。
Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。
注記このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。
3.2.1.1.5. CLI の使用によるクラスターからの Operator の削除
クラスター管理者は CLI を使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 -
ocコマンドがワークステーションにインストールされていること。
手順
サブスクライブされた Operator (例:
jaeger) の現行バージョンをcurrentCSVフィールドで確認します。$ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV
出力例
currentCSV: jaeger-operator.v1.8.2
サブスクリプション (例:
jaeger) を削除します。$ oc delete subscription jaeger -n openshift-operators
出力例
subscription.operators.coreos.com "jaeger" deleted
直前の手順で
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.2.2. Red Hat のロギングサブシステムを理解する
クラスター管理者は、ロギングシステムをデプロイし、ノードシステムの監査ログ、アプリケーションコンテナーログ、およびインフラストラクチャーログなどの OpenShift Container Platform クラスターからのすべてのログを集計できます。ロギングサブシステムは、クラスター全体からこれらのログを集約し、デフォルトのログストアに保存します。Kibana Web コンソールを使用して、ログデータを可視化 できます。
ロギングサブシステムは、次のタイプのログを集約します。
-
application: クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。 -
infrastructure: ジャーナルログなどの、クラスターで実行されるインフラストラクチャーコンポーネントおよび OpenShift Container Platform ノードで生成されるログ。インフラストラクチャーコンポーネントは、openshift*、kube*、またはdefaultプロジェクトで実行される Pod です。 -
audit: ノード監査システム (auditd) で生成されるログ (/var/log/audit/audit.log ファイルに保存される)、および Kubernetes apiserver および OpenShift apiserver の監査ログ。
内部 OpenShift Container Platform Elasticsearch ログストアは監査ログのセキュアなストレージを提供しないため、デフォルトで監査ログは内部 Elasticsearch インスタンスに保存されません。監査ログをデフォルトの内部 Elasticsearch ログストアに送信する必要がある場合 (Kibana で監査ログを表示するなど)、Forward audit logs to the log store で説明されているようにログ転送 API を使用する必要があります。
3.2.2.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.2.2.2. OpenShift Container Platform ロギングの共通用語集
この用語集は、OpenShift Container Platform Logging コンテンツで使用される一般的な用語を定義します。
- アノテーション
- アノテーションを使用して、メタデータをオブジェクトに添付できます。
- Cluster Logging Operator (CLO)
- Cluster Logging Operator は、アプリケーション、インフラストラクチャー、および監査ログの収集と転送を制御するための一連の API を提供します。
- カスタムリソース (CR)
-
CR は Kubernetes API のエクステンションです。OpenShift Container Platform Logging およびログ転送を設定するために、
ClusterLoggingおよびClusterLogForwarderカスタムリソースをカスタマイズできます。 - イベントルーター
- イベントルーターは、OpenShift Container Platform イベントを監視する Pod です。OpenShift Container Platform Logging を使用してログを収集します。
- Fluentd
- Fluentd は、各 OpenShift Container Platform ノードに常駐するログコレクターです。アプリケーション、インフラストラクチャー、および監査ログを収集し、それらをさまざまな出力に転送します。
- ガベージコレクション
- ガベージコレクションは、終了したコンテナーや実行中の Pod によって参照されていないイメージなどのクラスターリソースをクリーンアップするプロセスです。
- Elasticsearch
- Elasticsearch は、分散検索および分析エンジンです。OpenShift Container Platform は、OpenShift Container Platform Logging のデフォルトのログストアとして ELasticsearch を使用します。
- Elasticsearch Operator
- Elasticsearch Operator は、OpenShift Container Platform 上で Elasticsearch クラスターを実行するために使用されます。Elasticsearch Operator は、Elasticsearch クラスター操作のセルフサービスを提供し、OpenShift Container Platform Logging により使用されます。
- インデックス化
- インデックス作成は、データをすばやく見つけてアクセスするために使用されるデータ構造手法です。インデックスを作成すると、クエリーの処理時に必要なディスクアクセスの量が最小限に抑えられるため、パフォーマンスが最適化されます。
- JSON ロギング
- OpenShift Container Platform Logging Log Forwarding API を使用すると、JSON ログを解析して構造化されたオブジェクトにし、それらを OpenShift Container Platform Logging が管理する Elasticsearch またはログ転送 API でサポートされるその他のサードパーティーシステムに転送できます。
- Kibana
- Kibana は、ヒストグラム、折れ線グラフ、円グラフを使用して Elasticsearch データを照会、検出、視覚化するためのブラウザーベースのコンソールインターフェイスです。
- Kubernetes API サーバー
- Kubernetes API サーバーは、API オブジェクトのデータを検証して設定します。
- ラベル
- ラベルは、Pod などのオブジェクトのサブセットを整理および選択するために使用できるキーと値のペアです。
- ロギング
- OpenShift Container Platform Logging を使用すると、クラスター全体でアプリケーション、インフラストラクチャー、および監査ログを集約できます。また、ログをデフォルトのログストアに保存したり、サードパーティーのシステムに転送したり、デフォルトのログストアに保存されているログを照会して視覚化したりすることもできます。
- ロギングコレクター
- ロギングコレクターは、クラスターからログを収集してフォーマットし、ログストアまたはサードパーティーシステムに転送します。
- ログストア
- ログストアは、集約されたログを格納するために使用されます。デフォルトの Elasticsearch ログストアを使用、またはログを外部ログストアに転送できます。デフォルトのログストアは、短期の保存について最適化され、テストされています。
- ログビジュアライザー
- ログビジュアライザーは、ログ、グラフ、チャート、その他のメトリックなどの情報を表示するために使用できるユーザーインターフェイス (UI) コンポーネントです。現在の実装は Kibana です。
- node
- ノードは、OpenShift Container Platform クラスター内のワーカーマシンです。ノードは、仮想マシン (VM) または物理マシンのいずれかです。
- Operator
- Operator は、OpenShift Container Platform クラスターで Kubernetes アプリケーションをパッケージ化、デプロイ、および管理するための推奨される方法。Operator は、人間による操作に関する知識を取り入れて、簡単にパッケージ化してお客様と共有できるソフトウェアにエンコードします。
- pod
- Pod は、Kubernetes における最小の論理単位です。Pod は 1 つ以上のコンテナーで設定され、ワーカーノードで実行されます。
- ロールベースアクセス制御 (RBAC)
- RBAC は、クラスターユーザーとワークロードが、ロールを実行するために必要なリソースにのみアクセスできるようにするための重要なセキュリティーコントロールです。
- shards
- Elasticsearch は、Fluentd からのログデータをデータストアまたはインデックスに編成し、各インデックスをシャードと呼ばれる複数の部分に分割します。
- Taint
- テイントは、Pod が適切なノードに確実にスケジュールされるようにします。ノードに 1 つ以上のテイントを適用できます。
- 容認
- Pod に容認を適用できます。Tolerations を使用すると、スケジューラーは、テイントが一致する Pod をスケジュールできます。
- Web コンソール
- OpenShift Container Platform を管理するためのユーザーインターフェイス (UI)。
3.2.2.3. Red Hat OpenShift の logging サブシステムのデプロイについて
OpenShift Container Platform クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI コマンドを使用してロギングシステムをデプロイし、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator をインストールできます。Operator がインストールされたら、ClusterLogging カスタムリソース (CR) を作成して、ロギングサブシステム pod およびロギングサブシステムをサポートするために必要なその他のリソースをスケジュールします。Operator は、ロギングサブシステムのデプロイ、アップグレード、および保守を担当します。
ClusterLogging CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なロギングシステム環境を定義します。Red Hat OpenShift Logging Operator はロギングシステム CR を監視し、ロギングデプロイメントを適宜調整します。
管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。
詳細は、Configuring the log collector を参照してください。
3.2.2.3.1. JSON OpenShift コンテナープラットフォームロギング
JSON ロギングを使用して、JSON 文字列を構造化オブジェクトに解析するようにログ転送 API を設定できます。以下のタスクを実行します。
- JSON ログの解析
- Elasticsearch の JSON ログデータの設定
- JSON ログの Elasticsearch ログストアへの転送
3.2.2.3.2. Kubernetes イベントの収集および保存
OpenShift Container Platform イベントルーターは、Kubernetes イベントを監視し、それらを OpenShift Container Platform Logging によって収集できるようにログに記録する Pod です。イベントルーターは手動でデプロイする必要があります。
詳細は、About collecting and storing Kubernetes events を参照してください。
3.2.2.3.3. OpenShift Container Platform ロギングの更新
OpenShift Container Platform を使用すると、OpenShift Container Platform のロギングを更新できます。OpenShift Container Platform Logging の更新時には、以下の Operator を更新する必要があります。
- Elasticsearch Operator
- Cluster Logging Operator
詳細は、About updating OpenShift Container Platform Logging を参照してください。
3.2.2.3.4. クラスターダッシュボードの表示
OpenShift Container Platform Logging ダッシュボードには、クラスターレベルで Elasticsearch インスタンスに関する詳細を示すチャートが含まれています。これらのチャートは、問題の診断と予測に役立ちます。
詳細は、About viewing the cluster dashboard を参照してください。
3.2.2.3.5. OpenShift Container Platform ロギングのトラブルシューティング
次のタスクを実行してログの問題をトラブルシューティングできます。
- ロギングステータスの表示
- ログストアのステータスの表示
- ロギングアラートの理解
- Red Hat サポート用のロギングデータの収集
- Critical Alerts のトラブルシューティング
3.2.2.3.6. OpenShift Container Platform ロギングのアンインストール
ClusterLogging カスタムリソース (CR) を削除して、ログ集計を停止できます。CR の削除後に残る他のクラスターロギングコンポーネントがあり、これらはオプションで削除できます。
詳細は、About uninstalling OpenShift Container Platform Logging を参照してください。
3.2.2.3.7. フィールドのエクスポート
ロギングシステムはフィールドをエクスポートします。エクスポートされたフィールドはログレコードに存在し、Elasticsearch および Kibana から検索できます。
詳細は、About exporting fields を参照してください。
3.2.2.3.8. サブシステムコンポーネントのロギングについて
ロギングシステムコンポーネントには、すべてのノードおよびコンテナーログを収集し、それらをログストアに書き込む OpenShift Container Platform クラスターの各ノードにデプロイされるコレクターが含まれます。一元化された Web UI を使用し、集計されたデータを使用して高度な可視化 (visualization) およびダッシュボードを作成できます。
ロギングサブシステムの主なコンポーネントは次のとおりです。
- collection: これは、クラスターからログを収集し、それらをフォーマットし、ログストアに転送するコンポーネントです。現在の実装は Fluentd です。
- log store: これはログが保存される場所です。デフォルトの実装は Elasticsearch です。デフォルトの Elasticsearch ログストアを使用、またはログを外部ログストアに転送できます。デフォルトのログストアは、短期の保存について最適化され、テストされています。
- visualization: これは、ログ、グラフ、グラフなどを表示するために使用される UI コンポーネントです。現在の実装は Kibana です。
本書では、特筆されない限り、log store と Elasticsearch、visualization と Kibana、collection と Fluentd を区別せずに使用する場合があります。
3.2.2.3.9. ロギングコレクターについて
Red Hat OpenShift のロギングサブシステムは、コンテナーとノードのログを収集します。
デフォルトでは、ログコレクターは以下のソースを使用します。
- すべてのシステムログ用の journald
-
すべてのコンテナーログ用の
/var/log/containers/*.log
監査ログを収集するようにログコレクターを設定すると、/var/log/audit/audit.log から取得されます。
ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットです。システムおよびインフラストラクチャーのログは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からの journald ログメッセージによって生成されます。アプリケーションログは CRI-O コンテナーエンジンによって生成されます。Fluentd はこれらのソースからログを収集し、OpenShift Container Platform で設定したように内部または外部に転送します。
コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合は、ラベルやアノテーションなどの API サーバーからの情報は利用できない可能性があります。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡できない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。
利用可能なコンテナーランタイムは、ログメッセージのソースを特定するための最小限の情報を提供し、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、そのソースを追跡できる訳ではありません。
詳細は、Configuring the log collector を参照してください。
3.2.2.3.10. ログストアについて
デフォルトで、OpenShift Container Platform は Elasticsearch (ES) を使用してログデータを保存します。オプションで、Log Forwarder API を使用して、ログを外部ストアに転送できます。fluentd、rsyslog、kafka など、いくつかのタイプのストアがサポートされています。
ロギングサブシステム Elasticsearch インスタンスは、約 7 日間の短期ストレージ用に最適化およびテストされています。長期間ログを保持する必要がある場合は、データをサードパーティーのストレージシステムに移動することが推奨されます。
Elasticsearch は Fluentd からのログデータをデータストアまたは インデックス に編成し、それぞれのインデックスを シャード と呼ばれる複数の部分に分割します。これは、Elasticsearch クラスターの Elasticsearch ノードセット全体に分散されます。Elasticsearch を、レプリカ と呼ばれるシャードのコピーを作成するように設定できます。Elasticsearch はこれを Elasticsearch ノード全体に分散します。ClusterLogging カスタムリソース (CR) により、データの冗長性および耐障害性を確保するためにシャードを複製する方法を指定できます。また、ClusterLogging CR の保持ポリシーを使用して各種のログが保持される期間を指定することもできます。
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
Red Hat OpenShift Logging Operator および OpenShift Elasticsearch Operator は、各 Elasticsearch ノードが独自のストレージボリュームを含む一意のデプロイメントを使用してデプロイされるようにします。ClusterLogging カスタムリソース (CR) を使用して Elasticsearch ノードの数を適宜増やすことができます。ストレージの設定に関する考慮事項は、Elasticsearch ドキュメント を参照してください。
可用性の高い Elasticsearch 環境には 3 つ以上の Elasticsearch ノードが必要で、それぞれが別のホストに置かれる必要があります。
Elasticsearch インデックスに適用されているロールベースアクセス制御 (RBAC) は、開発者のログの制御アクセスを可能にします。管理者はすべてのログに、開発者は各自のプロジェクトのログにのみアクセスできます。
詳細は、Configuring the log store を参照してください。
3.2.2.3.11. ロギングの可視化について
OpenShift Container Platform は Kibana を使用して、Fluentd によって収集され、Elasticsearch によってインデックス化されるログデータを表示します。
Kibana は、ヒストグラム、線グラフ、円グラフその他の可視化機能を使用して Elasticsearch データをクエリーし、検出し、可視化するためのブラウザーベースのコンソールインターフェイスです。
詳細は、Configuring the log visualizer を参照してください。
3.2.2.3.12. イベントのルーティングについて
イベントルーターは、OpenShift Container Platform イベントを監視する pod であるため、Red Hat のロギングサブシステムによってイベントを収集できます。イベントルーターはすべてのプロジェクトからイベントを収集し、それらを STDOUT に書き込みます。Fluentd はそれらのイベントを収集し、それらを OpenShift Container Platform Elasticsearch インスタンスに転送します。Elasticsearch はイベントを infra インデックスにインデックス化します。
イベントルーターは手動でデプロイする必要があります。
詳細は、Collecting and storing Kubernetes events を参照してください。
3.2.2.3.13. ログ転送
デフォルトでは、Red Hat OpenShift のロギングサブシステムは、ClusterLogging カスタムリソース (CR) で定義されているデフォルトの内部 Elasticsearch ログストアにログを送信します。ログを他のログアグリゲーターに転送する必要がある場合は、ログ転送機能を使用してログをクラスター内外の特定のエンドポイントに送信できます。
詳細は、Forwarding logs to third-party systems を参照してください。
3.2.2.4. Vector について
Vector は、ロギングサブシステムの Fluentd の代替として提供されるログコレクターです。
次の出力がサポートされています。
-
elasticsearch。外部 Elasticsearch インスタンス。elasticsearch出力では、TLS 接続を使用できます。 -
kafka。Kafka ブローカー。kafka出力は、セキュリティーで保護されていない接続または TLS 接続を使用できます。 -
loki。水平的にスケーラビリティーが高く、マルチテナントログ集約システムです i。
3.2.2.4.1. Vector の有効化
Vector はデフォルトでは有効になっていません。以下のステップを使用して、OpenShift Container Platform クラスターで Vector を有効にします。
Vector は、FIPS 対応クラスターをサポートしていません。
前提条件
- OpenShift Container Platform: 4.11
- 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: {}関連情報
3.2.2.4.2. コレクター機能
表3.1 ログソース
| 機能 | Fluentd | Vector |
|---|---|---|
| アプリコンテナーのログ | ✓ | ✓ |
| アプリ固有のルーティング | ✓ | ✓ |
| namespace 別のアプリ固有のルーティング | ✓ | ✓ |
| インフラコンテナーログ | ✓ | ✓ |
| インフラジャーナルログ | ✓ | ✓ |
| Kube API 監査ログ | ✓ | ✓ |
| OpenShift API 監査ログ | ✓ | ✓ |
| Open Virtual Network (OVN) 監査ログ | ✓ | ✓ |
表3.2 出力
| 機能 | Fluentd | Vector |
|---|---|---|
| Elasticsearch v5-v7 | ✓ | ✓ |
| Fluent 転送 | ✓ | |
| Syslog RFC3164 | ✓ | ✓ (Logging 5.7+) |
| Syslog RFC5424 | ✓ | ✓ (Logging 5.7+) |
| Kafka | ✓ | ✓ |
| Cloudwatch | ✓ | ✓ |
| Loki | ✓ | ✓ |
| HTTP | ✓ | ✓ (Logging 5.7+) |
表3.3 認証および認可
| 機能 | Fluentd | Vector |
|---|---|---|
| Elasticsearch 証明書 | ✓ | ✓ |
| Elasticsearch ユーザー名/パスワード | ✓ | ✓ |
| Cloudwatch キー | ✓ | ✓ |
| クラウドウォッチ STS | ✓ | ✓ |
| Kafka 証明書 | ✓ | ✓ |
| Kafka のユーザー名/パスワード | ✓ | ✓ |
| Kafka SASL | ✓ | ✓ |
| Loki ベアラートークン | ✓ | ✓ |
表3.4 正規化と変換
| 機能 | Fluentd | Vector |
|---|---|---|
| Viaq データモデル - アプリ | ✓ | ✓ |
| Viaq データモデル - インフラ | ✓ | ✓ |
| Viaq データモデル - インフラ (ジャーナル) | ✓ | ✓ |
| Viaq データモデル - Linux 監査 | ✓ | ✓ |
| Viaq データモデル - kube-apiserver 監査 | ✓ | ✓ |
| Viaq データモデル - OpenShift API 監査 | ✓ | ✓ |
| Viaq データモデル - OVN | ✓ | ✓ |
| ログレベルの正規化 | ✓ | ✓ |
| JSON 解析 | ✓ | ✓ |
| 構造化インデックス | ✓ | ✓ |
| 複数行エラー検出 | ✓ | ✓ |
| マルチコンテナー/分割インデックス | ✓ | ✓ |
| ラベルのフラット化 | ✓ | ✓ |
| CLF 静的ラベル | ✓ | ✓ |
表3.5 チューニング
| 機能 | Fluentd | Vector |
|---|---|---|
| Fluentd readlinelimit | ✓ | |
| Fluentd バッファー | ✓ | |
| -chunklimitsize | ✓ | |
| - totallimitsize | ✓ | |
| - overflowaction | ✓ | |
| -flushThreadCount | ✓ | |
| - flushmode | ✓ | |
| - flushinterval | ✓ | |
| - retrywait | ✓ | |
| - retrytype | ✓ | |
| - retrymaxinterval | ✓ | |
| - retrytimeout | ✓ |
表3.6 制約
| 機能 | Fluentd | Vector |
|---|---|---|
| メトリクス | ✓ | ✓ |
| ダッシュボード | ✓ | ✓ |
| アラート | ✓ |
表3.7 その他
| 機能 | Fluentd | Vector |
|---|---|---|
| グローバルプロキシーサポート | ✓ | ✓ |
| x86 サポート | ✓ | ✓ |
| ARM サポート | ✓ | ✓ |
| PowerPC サポート | ✓ | ✓ |
| IBM Z サポート | ✓ | ✓ |
| IPv6 サポート | ✓ | ✓ |
| ログイベントのバッファーリング | ✓ | |
| 非接続クラスター | ✓ | ✓ |
3.2.3. Red Hat のロギングサブシステムのインストール
OpenShift Elasticsearch と Red Hat Logging Operators をデプロイすることにより、Red Hat のロギングサブシステムをインストールできます。OpenShift Elasticsearch Operator は、OpenShift Logging によって使用される Elasticsearch クラスターを作成し、管理します。ロギングサブシステム Operator は、ロギングスタックのコンポーネントを作成および管理します。
ロギングサブシステムを OpenShift Container Platform にデプロイするためのプロセスには以下が含まれます。
- Logging サブシステムのストレージに関する考慮事項 を確認します。
- OpenShift Container Platform Web コンソール、または CLI を使用した OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator のインストール
3.2.3.1. Web コンソールを使用した Red Hat のロギングサブシステムのインストール
OpenShift Container Platform Web コンソールを使用して OpenShift Elasticsearch および Red Hat OpenShift Logging Operator をインストールすることができます。
デフォルトの Elasticsearch ログストアを使用しない場合、内部 Elasticsearch logStore、Kibana visualization コンポーネントを ClusterLogging カスタムリソース (CR) から削除することができます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。詳細は、Removing unused components if you do not use the default Elasticsearch log store.を参照してください。
前提条件
Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。
注記永続ストレージにローカルボリュームを使用する場合は、
LocalVolumeオブジェクトのvolumeMode: blockで記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。Elasticsearch はメモリー集約型アプリケーションです。デフォルトで、OpenShift Container Platform はメモリー要求および 16 GB の制限を持つ 3 つの Elasticsearch ノードをインストールします。OpenShift Container Platform ノードの最初の 3 つのセットには、Elasticsearch をクラスター内で実行するのに十分なメモリーがない可能性があります。Elasticsearch に関連するメモリーの問題が発生した場合、既存ノードのメモリーを増やすのではなく、Elasticsearch ノードをクラスターにさらに追加します。
手順
OpenShift Container Platform Web コンソールを使用して OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator をインストールするには、以下を実行します。
OpenShift Elasticsearch Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から OpenShift Elasticsearch Operator を選択し、Install をクリックします。
- All namespaces on the cluster が Installation Mode で選択されていることを確認します。
openshift-operators-redhat が Installed Namespace で選択されていることを確認します。
openshift-operators-redhatnamespace を指定する必要があります。openshift-operatorsnamespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。Enable operator recommended cluster monitoring on this namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"ラベルを設定します。クラスターモニタリングがopenshift-operators-redhatnamespace を収集できるように、このオプションを選択する必要があります。- Update Channel として stable-5.x を選択します。
Approval Strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
- Operators → Installed Operators ページに切り替えて、OpenShift Elasticsearch Operator がインストールされていることを確認します。
- Status が Succeeded の状態で、OpenShift Elasticsearch Operator が すべてのプロジェクトに一覧表示されていることを確認します。
Red Hat OpenShift Logging Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から Red Hat OpenShift Logging を選択し、Install をクリックします。
- A specific namespace on the cluster が Installation Mode で選択されていることを確認します。
- Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。
Enable operator recommended cluster monitoring on this namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"ラベルを設定します。クラスターモニタリングがopenshift-loggingnamespace を収集できるように、このオプションを選択する必要があります。- Update Channel として stable-5.x を選択します。
Approval Strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
- Operators → Installed Operators ページに切り替えて、Red Hat OpenShift Logging Operator がインストールされていることを確認します。
Red Hat OpenShift Logging が Status が Succeeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operators → Installed Operators ページに切り替え、Status 列でエラーまたは失敗の有無を確認します。
-
Workloads → Pods ページに切り替え、
openshift-loggingプロジェクトの Pod で問題を報告しているログの有無を確認します。
OpenShift Logging インスタンスを作成します。
- Administration → Custom Resource Definitions ページに切り替えます。
- Custom Resource Definitions ページで、ClusterLogging をクリックします。
- Custom Resource Definition details ページで、Actions メニューから View Instances を選択します。
ClusterLoggings ページで、 Create ClusterLogging をクリックします。
データを読み込むためにページの更新が必要になる場合があります。
YAML フィールドで、コードを以下に置き換えます。
注記このデフォルトの OpenShift Logging 設定は各種の環境をサポートすることが予想されます。OpenShift Logging クラスターに加えることのできる変更の詳細は、ロギングシステムコンポーネントのチューニングおよび設定に関するトピックを確認してください。
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" spec: managementState: "Managed" 2 logStore: type: "elasticsearch" 3 retentionPolicy: 4 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 5 storage: storageClassName: "<storage_class_name>" 6 size: 200G resources: 7 limits: memory: "16Gi" requests: memory: "16Gi" proxy: 8 resources: limits: memory: 256Mi requests: memory: 256Mi redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" 9 kibana: replicas: 1 collection: logs: type: "fluentd" 10 fluentd: {}
- 1
- 名前は
instanceである必要があります。 - 2
- OpenShift Logging の管理状態。OpenShift Logging のデフォルト値を変更する場合は、これを
Unmanaged(管理外) に設定することが求められる場合があります。ただし、管理外のデプロイメントは OpenShift Logging が管理対象の状態に戻されるまで更新を受信しません。 - 3
- Elasticsearch の設定に必要な設定。CR を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。
- 4
- Elasticsearch が各ログソースを保持する期間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、7 日の場合は
7dとなります。maxAgeよりも古いログは削除されます。各ログソースの保持ポリシーを指定する必要があります。指定しないと、Elasticsearch インデックスはそのソースに対して作成されません。 - 5
- Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。
- 6
- Elasticsearch ストレージの既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。ストレージクラスを指定しないと、OpenShift Logging は一時ストレージを使用します。
- 7
- 必要に応じて CPU およびメモリー要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は
16Giであり、CPU 要求の場合は1です。 - 8
- 必要に応じて Elasticsearch プロキシーの CPU およびメモリーの制限および要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は
256Mi、CPU 要求の場合は100mです。 - 9
- Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana ノードの CPU およびメモリーを設定できます。詳細は、ログビジュアライザーの設定 を参照してください。
- 10
- Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細はFluentd の設定を参照してください。
注記Elasticsearch コントロールプレーンノードの最大数は 3 です。
3を超えるnodeCountを指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。コントロールプレーンノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。たとえば、
nodeCount=4の場合に、以下のノードが作成されます。$ oc get deployment
出力例
cluster-logging-operator 1/1 1 1 18h elasticsearch-cd-x6kdekli-1 0/1 1 0 6m54s elasticsearch-cdm-x6kdekli-1 1/1 1 1 18h elasticsearch-cdm-x6kdekli-2 0/1 1 0 6m49s elasticsearch-cdm-x6kdekli-3 0/1 1 0 6m44s
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
-
Create をクリックします。これにより、ロギングサブシステムコンポーネント、
Elasticsearchカスタムリソースとコンポーネント、および Kibana インターフェイスが作成されます。
インストールを確認します。
- Workloads → Pods ページに切り替えます。
openshift-logging プロジェクトを選択します。
以下の一覧のような OpenShift Logging、Elasticsearch、Fluentd、および Kibana のいくつかの Pod が表示されるはずです。
- cluster-logging-operator-cb795f8dc-xkckc
- elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
- elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
- elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
- fluentd-2c7dg
- fluentd-9z7kk
- fluentd-br7r2
- fluentd-fn2sb
- fluentd-pb2f8
- fluentd-zqgqx
- kibana-7fb4fd4cc9-bvt4p
3.2.3.2. インストール後のタスク
Kibana を使用する場合、Kibana のデータを確認し、び可視化するために、Kibana インデックスパターンおよびビジュアライゼーションを手動で作成する 必要があります。
クラスターネットワークプロバイダーがネットワークの分離を実施している場合、ロギングシステム Operator が含まれるプロジェクト間のネットワークトラフィックを許可します。
3.2.3.3. CLI を使用した Red Hat OpenShift のロギングサブシステムのインストール
OpenShift Container Platform CLI を使用して OpenShift Elasticsearch および Red Hat OpenShift Logging Operator をインストールすることができます。
前提条件
Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。
注記永続ストレージにローカルボリュームを使用する場合は、
LocalVolumeオブジェクトのvolumeMode: blockで記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。Elasticsearch はメモリー集約型アプリケーションです。デフォルトで、OpenShift Container Platform はメモリー要求および 16 GB の制限を持つ 3 つの Elasticsearch ノードをインストールします。OpenShift Container Platform ノードの最初の 3 つのセットには、Elasticsearch をクラスター内で実行するのに十分なメモリーがない可能性があります。Elasticsearch に関連するメモリーの問題が発生した場合、既存ノードのメモリーを増やすのではなく、Elasticsearch ノードをクラスターにさらに追加します。
手順
CLI を使用して OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator をインストールするには、以下を実行します。
OpenShift Elasticsearch Operator の namespace を作成します。
OpenShift Elasticsearch Operator の namespace オブジェクト YAML ファイル (
eo-namespace.yamlなど) を作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-operators-redhat 1 annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-monitoring: "true" 2
- 1
openshift-operators-redhatnamespace を指定する必要があります。メトリクスとの競合が発生する可能性を防ぐには、Prometheus のクラスターモニタリングスタックを、openshift-operatorsnamespace からではなく、openshift-operators-redhatnamespace からメトリクスを収集するように設定する必要があります。openshift-operatorsnamespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。- 2
- 文字列。クラスターモニタリングが
openshift-operators-redhatnamespace を収集できるように、このラベルを上記のように指定する必要があります。
namespace を作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f eo-namespace.yaml
Red Hat OpenShift Logging Operator の namespace を作成します。
Red Hat OpenShift Logging Operator の namespace オブジェクト YAML ファイル (
olo-namespace.yamlなど) を作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-logging annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-monitoring: "true"namespace を作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f olo-namespace.yaml
以下のオブジェクトを作成して OpenShift Elasticsearch Operator をインストールします。
OpenShift Elasticsearch Operator の Operator グループオブジェクトの YAML ファイル (
eo-og.yamlなど) を作成します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-operators-redhat namespace: openshift-operators-redhat 1 spec: {}- 1
openshift-operators-redhatnamespace を指定する必要があります。
Operator グループオブジェクトを作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f eo-og.yaml
Subscription オブジェクト YAML ファイル (
eo-sub.yamlなど) を作成し、namespace を OpenShift Elasticsearch Operator にサブスクライブします。Subscription の例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: "elasticsearch-operator" namespace: "openshift-operators-redhat" 1 spec: channel: "stable-5.1" 2 installPlanApproval: "Automatic" 3 source: "redhat-operators" 4 sourceNamespace: "openshift-marketplace" name: "elasticsearch-operator"
- 1
openshift-operators-redhatnamespace を指定する必要があります。- 2
- チャネルとして
stableまたはstable-5.<x>を指定します。以下の注意点を参照してください。 - 3
Automaticにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。Manualには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。- 4
redhat-operatorsを指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれるネットワークが制限された環境でインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成される CatalogSource オブジェクトの名前を指定します。
注記stableを指定すると、最新の安定したリリースの現行バージョンがインストールされます。installPlanApproval: "Automatic"でstable使用すると、Operatar が自動的に最新の安定したメジャーおよびマイナーリリースにアップグレードします。stable-5.<x>を指定すると、特定のメジャーリリースの現在のマイナーバージョンがインストールされます。installPlanApproval: "Automatic"でstable-5.<x>を使用すると、xで指定したメジャーリリース内で最新の安定マイナーリリースに Operator が自動的にアップグレードされます。Subscription オブジェクトを作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f eo-sub.yaml
OpenShift Elasticsearch Operator は
openshift-operators-redhatnamespace にインストールされ、クラスター内の各プロジェクトにコピーされます。Operator のインストールを確認します。
$ oc get csv --all-namespaces
出力例
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE default elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded kube-node-lease elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded kube-public elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded kube-system elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded openshift-apiserver-operator elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded openshift-apiserver elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded openshift-authentication-operator elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded openshift-authentication elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.1.0-202007012112.p0 Succeeded ...
それぞれの namespace には OpenShift Elasticsearch Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。
以下のオブジェクトを作成して Red Hat OpenShift Logging Operator をインストールします。
Red Hat OpenShift Logging Operator の Operator グループオブジェクトの YAML ファイル (
olo-og.yamlなど) を作成します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: cluster-logging namespace: openshift-logging 1 spec: targetNamespaces: - openshift-logging 2
OperatorGroup オブジェクトを作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f olo-og.yaml
Subscription オブジェクト YAML ファイル (
olo-sub.yamlなど) を作成し、namespace を Red Hat OpenShift Logging Operator にサブスクライブします。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cluster-logging namespace: openshift-logging 1 spec: channel: "stable" 2 name: cluster-logging source: redhat-operators 3 sourceNamespace: openshift-marketplace
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f olo-sub.yaml
Red Hat OpenShift Logging Operator は
openshift-loggingnamespace にインストールされます。Operator のインストールを確認します。
openshift-loggingnamespace には Red Hat OpenShift Logging Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。$ oc get csv -n openshift-logging
出力例
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE ... openshift-logging clusterlogging.5.1.0-202007012112.p0 OpenShift Logging 5.1.0-202007012112.p0 Succeeded ...
OpenShift Logging インスタンスを作成します。
Red Hat OpenShift Logging Operator のインスタンスオブジェクト YAML ファイル (
olo-instance.yamlなど) を作成します。注記このデフォルトの OpenShift Logging 設定は各種の環境をサポートすることが予想されます。OpenShift Logging クラスターに加えることのできる変更の詳細は、ロギングシステムコンポーネントのチューニングおよび設定に関するトピックを確認してください。
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" spec: managementState: "Managed" 2 logStore: type: "elasticsearch" 3 retentionPolicy: 4 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 5 storage: storageClassName: "<storage-class-name>" 6 size: 200G resources: 7 limits: memory: "16Gi" requests: memory: "16Gi" proxy: 8 resources: limits: memory: 256Mi requests: memory: 256Mi redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" 9 kibana: replicas: 1 collection: logs: type: "fluentd" 10 fluentd: {}
- 1
- 名前は
instanceである必要があります。 - 2
- OpenShift Logging の管理状態。OpenShift Logging のデフォルト値を変更する場合は、これを
Unmanaged(管理外) に設定することが求められる場合があります。ただし、管理外のデプロイメントは OpenShift Logging が管理対象の状態に戻されるまで更新を受信しません。デプロイメントを管理対象の状態に戻すと、加えた変更が元に戻される可能性があります。 - 3
- Elasticsearch の設定に必要な設定。カスタムリソース (CR) を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。
- 4
- Elasticsearch が各ログソースを保持する期間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、7 日の場合は
7dとなります。maxAgeよりも古いログは削除されます。各ログソースの保持ポリシーを指定する必要があります。指定しないと、Elasticsearch インデックスはそのソースに対して作成されません。 - 5
- Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。
- 6
- Elasticsearch ストレージの既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。ストレージクラスを指定しない場合、OpenShift Container Platform は一時ストレージのみの OpenShift Logging をデプロイします。
- 7
- 必要に応じて CPU およびメモリー要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるます。デフォルト値は、メモリー要求の場合は
16Giであり、CPU 要求の場合は1です。 - 8
- 必要に応じて Elasticsearch プロキシーの CPU およびメモリーの制限および要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は
256Mi、CPU 要求の場合は100mです。 - 9
- Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana Pod の CPU およびメモリーを設定できます。詳細は、ログビジュアライザーの設定 を参照してください。
- 10
- Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細はFluentd の設定を参照してください。
注記Elasticsearch コントロールプレーンノードの最大数は 3 です。
3を超えるnodeCountを指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。コントロールプレーンノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。たとえば、
nodeCount=4の場合に、以下のノードが作成されます。$ oc get deployment
出力例
cluster-logging-operator 1/1 1 1 18h elasticsearch-cd-x6kdekli-1 1/1 1 0 6m54s elasticsearch-cdm-x6kdekli-1 1/1 1 1 18h elasticsearch-cdm-x6kdekli-2 1/1 1 0 6m49s elasticsearch-cdm-x6kdekli-3 1/1 1 0 6m44s
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
インスタンスを作成します。
$ oc create -f <file-name>.yaml
以下に例を示します。
$ oc create -f olo-instance.yaml
これにより、ロギングサブシステムコンポーネント、
Elasticsearchカスタムリソースとコンポーネント、および Kibana インターフェイスが作成されます。
openshift-logging プロジェクトに Pod を一覧表示して、インストールを検証します。
次のリストのように、Logging サブシステムのコンポーネントの Pod がいくつか表示されます。
$ oc get pods -n openshift-logging
出力例
NAME READY STATUS RESTARTS AGE cluster-logging-operator-66f77ffccb-ppzbg 1/1 Running 0 7m elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp 2/2 Running 0 2m40s elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc 2/2 Running 0 2m36s elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2 2/2 Running 0 2m4s collector-587vb 1/1 Running 0 2m26s collector-7mpb9 1/1 Running 0 2m30s collector-flm6j 1/1 Running 0 2m33s collector-gn4rn 1/1 Running 0 2m26s collector-nlgb6 1/1 Running 0 2m30s collector-snpkt 1/1 Running 0 2m28s kibana-d6d5668c5-rppqm 2/2 Running 0 2m39s
3.2.3.4. インストール後のタスク
Kibana を使用する場合、Kibana のデータを確認し、び可視化するために、Kibana インデックスパターンおよびビジュアライゼーションを手動で作成する 必要があります。
クラスターネットワークプロバイダーがネットワークの分離を実施している場合、ロギングシステム Operator が含まれるプロジェクト間のネットワークトラフィックを許可します。
3.2.3.4.1. Kibana インデックスパターンの定義
インデックスパターンは、可視化する必要のある Elasticsearch インデックスを定義します。Kibana でデータを確認し、可視化するには、インデックスパターンを作成する必要があります。
前提条件
Kibana で infra および audit インデックスを表示するには、ユーザーには
cluster-adminロール、cluster-readerロール、または両方のロールが必要です。デフォルトのkubeadminユーザーには、これらのインデックスを表示するための適切なパーミッションがあります。default、kube-およびopenshift-プロジェクトで Pod およびログを表示できる場合に、これらのインデックスにアクセスできるはずです。以下のコマンドを使用して、現在のユーザーが適切なパーミッションを持っているかどうかを確認できます。$ oc auth can-i get pods/log -n <project>
出力例
yes
注記監査ログは、デフォルトでは内部 OpenShift Container Platform Elasticsearch インスタンスに保存されません。Kibana で監査ログを表示するには、ログ転送 API を使用して監査ログの
default出力を使用するパイプラインを設定する必要があります。- Elasticsearch ドキュメントは、インデックスパターンを作成する前にインデックス化する必要があります。これは自動的に実行されますが、新規または更新されたクラスターでは数分の時間がかかる可能性があります。
手順
Kibana でインデックスパターンを定義し、ビジュアライゼーションを作成するには、以下を実行します。
-
OpenShift Container Platform コンソールで、Application Launcher
をクリックし、Logging を選択します。
Management → Index Patterns → Create index pattern をクリックして Kibana インデックスパターンを作成します。
-
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
appという名前のインデックスパターンを作成し、@timestamp時間フィールドを使用してコンテナーログを表示する必要があります。 -
管理ユーザーはそれぞれ、最初に Kibana にログインする際に、
@timestamp時間フィールドを使用してapp、infraおよびauditインデックスのインデックスパターンを作成する必要があります。
-
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
- 新規インデックスパターンから Kibana のビジュアライゼーション (Visualization) を作成します。
3.2.3.4.2. ネットワークの分離が有効にされている場合のプロジェクト間のトラフィックの許可
クラスターネットワークプロバイダーはネットワークの分離を有効にする可能性があります。その場合、OpenShift Logging によってデプロイされる Operator が含まれるプロジェクト間のネットワークトラフィックを許可する必要があります。
ネットワークの分離は、異なるプロジェクトにある Pod およびサービス間のネットワークトラフィックをブロックします。ロギングシステムは、OpenShift Elasticsearch Operator を openshift-operators-redhat プロジェクトにインストールし、Red Hat OpenShift Logging Operator を openshift-logging プロジェクトにインストールします。したがって、これら 2 つのプロジェクト間のトラフィックを許可する必要があります。
OpenShift Container Platform は、2 つのサポート対象のオプションをデフォルトの Container Network Interface (CNI) ネットワークプロバイダー、OpenShift SDN および OVN-Kubernetes 用に提供します。これら 2 つのプロバイダーはさまざまなネットワーク分離ポリシーを実装します。
OpenShift SDN には 3 つのモードがあります。
- network policy (ネットワークポリシー)
- これはデフォルトモードになります。ポリシーが定義されていない場合は、すべてのトラフィックを許可します。ただし、ユーザーがポリシーを定義する場合、通常はすべてのトラフィックを拒否し、例外を追加して開始します。このプロセスでは、異なるプロジェクトで実行されているアプリケーションが破損する可能性があります。そのため、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可します。
- multitenant (マルチテナント)
- このモードは、ネットワークの分離を実行します。2 つのロギング関連のプロジェクトを結合して、それらのプロジェクト間のトラフィックを許可します。
- subnet (サブネット)
- このモードでは、すべてのトラフィックを許可します。ネットワーク分離は実行しません。アクションは不要です。
OVN-Kubernetes は常に ネットワークポリシー を使用します。そのため、OpenShift SDN の場合と同様に、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可する必要があります。
手順
multitenant モードで OpenShift SDN を使用している場合は、2 つのプロジェクトに参加します。以下に例を示します。
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
または、network policy の OpenShift SDN および OVN-Kubernetes の場合は、以下の操作を実行します。
openshift-operators-redhatnamespace にラベルを設定します。以下に例を示します。$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
openshift-operators-redhat、openshift-monitoring、およびopenshift-ingressプロジェクトから openshift-logging プロジェクトへの入力を許可する、openshift-loggingnamespace にネットワークポリシーオブジェクトを作成します。以下に例を示します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring-ingress-operators-redhat spec: ingress: - from: - podSelector: {} - from: - namespaceSelector: matchLabels: project: "openshift-operators-redhat" - from: - namespaceSelector: matchLabels: name: "openshift-monitoring" - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress
3.2.4. ロギングデプロイメントの設定
3.2.4.1. クラスターロギングカスタムリソースについて
Red Hat OpenShift のロギングサブシステムを設定するには、ClusterLogging カスタムリソース (CR) をカスタマイズします。
3.2.4.1.1. ClusterLogging カスタムリソースについて
ロギングサブシステム環境に変更を加えるには、ClusterLogging カスタムリソース (CR) を作成および変更します。
CR の作成または変更方法については、このドキュメントで適宜説明されます。
次の例は、ロギングサブシステムの一般的なカスタムリソースを示しています。
ClusterLogging カスタムリソース (CRD) のサンプル
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" 2 spec: managementState: "Managed" 3 logStore: type: "elasticsearch" 4 retentionPolicy: application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 resources: limits: memory: 16Gi requests: cpu: 500m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: 5 type: "kibana" kibana: resources: limits: memory: 736Mi requests: cpu: 100m memory: 736Mi replicas: 1 collection: 6 logs: type: "fluentd" fluentd: resources: limits: memory: 736Mi requests: cpu: 100m memory: 736Mi
3.2.4.2. ロギングコレクターの設定
Red Hat OpenShift のロギングサブシステムは、クラスターからオペレーションとアプリケーションログを収集し、Kubernetes Pod とプロジェクトメタデータでデータを強化します。
ログコレクターの CPU およびメモリー制限を設定し、ログコレクター pod を特定のノードに移動 できます。ログコレクターに対するサポートされるすべての変更は、ClusterLogging カスタムリソース (CR) の spec.collection.log.fluentd スタンザを使用して実行できます。
3.2.4.2.1. サポートされる設定
Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。本書で説明されている設定以外の設定を使用する場合、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。
OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合、Red Hat OpenShift Logging Operator または OpenShift Elasticsearch Operator を Unmanaged (管理外) に設定する 必要があります。管理外の OpenShift Logging 環境は サポート外 であり、OpenShift Logging を Managed に戻すまで変更を受信しません。
3.2.4.2.2. ロギングコレクター Pod の表示
Fluentd ロギングコレクター Pod およびそれらが実行されている対応するノードを表示できます。Fluentd ロギングコレクター Pod は openshift-logging プロジェクトでのみ実行されます。
手順
-
openshift-loggingプロジェクトで以下のコマンドを実行し、Fluentd ロギングコレクター Pod とそれらの詳細を表示します。
$ oc get pods --selector component=collector -o wide -n openshift-logging
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES fluentd-8d69v 1/1 Running 0 134m 10.130.2.30 master1.example.com <none> <none> fluentd-bd225 1/1 Running 0 134m 10.131.1.11 master2.example.com <none> <none> fluentd-cvrzs 1/1 Running 0 134m 10.130.0.21 master3.example.com <none> <none> fluentd-gpqg2 1/1 Running 0 134m 10.128.2.27 worker1.example.com <none> <none> fluentd-l9j7j 1/1 Running 0 134m 10.129.2.31 worker2.example.com <none> <none>
3.2.4.2.3. ログコレクター CPU およびメモリー制限の設定
ログコレクターは、CPU とメモリー制限の両方への調整を許可します。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: collection: logs: fluentd: resources: limits: 1 memory: 736Mi requests: cpu: 100m memory: 736Mi- 1
- 必要に応じて CPU、メモリー制限および要求を指定します。表示される値はデフォルト値です。
3.2.4.2.4. ログフォワーダーの高度な設定
Red Hat OpenShift のロギングサブシステムには、Fluentd ログ転送のパフォーマンスを調整するために使用できる複数の Fluentd パラメーターが含まれています。これらのパラメーターを使用すると、以下の Fluentd の動作を変更できます。
- チャンクおよびチャンクのバッファーサイズ
- チャンクのフラッシュ動作
- チャンク転送の再試行動作
Fluentd は、チャンク という単一の Blob でログデータを収集します。Fluentd がチャンクを作成する際に、チャンクは ステージ にあると見なされます。ここでチャンクはデータで一杯になります。チャンクが一杯になると、Fluentd はチャンクを キュー に移動します。ここでチャンクはフラッシュされる前か、送信先に書き込まれるまで保持されます。Fluentd は、ネットワークの問題や送信先での容量の問題などのさまざまな理由でチャンクをフラッシュできない場合があります。チャンクをフラッシュできない場合、Fluentd は設定通りにフラッシュを再試行します。
OpenShift Container Platform のデフォルトで、Fluentd は 指数関数的バックオフ 方法を使用してフラッシュを再試行します。この場合、Fluentd はフラッシュを再試行するまで待機する時間を 2 倍にします。これは、送信先への接続要求を減らすのに役立ちます。指数バックオフを無効にし、代わりに 定期的な 再試行方法を使用できます。これは、指定の間隔でチャンクのフラッシュを再試行します。
これらのパラメーターは、待ち時間とスループット間のトレードオフを判断するのに役立ちます。
- Fluentd のスループットを最適化するには、これらのパラメーターを使用して、より大きなバッファーおよびキューを設定し、フラッシュを遅延し、再試行の間隔の長く設定することで、ネットワークパケット数を減らすことができます。より大きなバッファーにはノードのファイルシステムでより多くの領域が必要になることに注意してください。
- 待機時間が低い場合に最適化するには、パラメーターを使用してすぐにデータを送信し、バッチの蓄積を回避し、キューとバッファーが短くして、より頻繁にフラッシュおよび再試行を使用できます。
ClusterLogging カスタムリソース (CR) で以下のパラメーターを使用して、チャンクおよびフラッシュ動作を設定できます。次に、パラメーターは Fluentd で使用するために Fluentd 設定マップに自動的に追加されます。
これらのパラメーターの特徴は以下の通りです。
- ほとんどのユーザーには関連性がありません。デフォルト設定で、全般的に良いパフォーマンスが得られるはずです。
- Fluentd 設定およびパフォーマンスに関する詳しい知識を持つ上級ユーザーのみが対象です。
- パフォーマンスチューニングのみを目的とします。ロギングの機能面に影響を与えることはありません。
表3.8 高度な Fluentd 設定パラメーター
| パラメーター | 説明 | デフォルト |
|---|---|---|
|
| 各チャンクの最大サイズ。Fluentd はこのサイズに達するとデータのチャンクへの書き込みを停止します。次に、Fluentd はチャンクをキューに送信し、新規のチャンクを開きます。 |
|
|
| ステージおよびキューの合計サイズであるバッファーの最大サイズ。バッファーサイズがこの値を超えると、Fluentd はデータのチャンクへの追加を停止し、エラーを出して失敗します。チャンクにないデータはすべて失われます。 |
|
|
|
チャンクのフラッシュの間隔。 |
|
|
| フラッシュを実行する方法:
|
|
|
| チャンクのフラッシュを実行するスレッドの数。スレッドの数を増やすと、フラッシュのスループットが改善し、ネットワークの待機時間が非表示になります。 |
|
|
| キューが一杯になると、チャンク動作は以下のようになります。
|
|
|
|
|
|
|
| フラッシュに失敗する場合の再試行方法:
|
|
|
| レコードが破棄される前に再試行を試みる最大時間間隔。 |
|
|
| 次のチャンクのフラッシュまでの時間 (秒単位)。 |
|
Fluentd チャンクのライフサイクルの詳細は、Fluentd ドキュメントの Buffer Plugins を参照してください。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
以下のパラメーターを追加または変更します。
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: forwarder: fluentd: buffer: chunkLimitSize: 8m 1 flushInterval: 5s 2 flushMode: interval 3 flushThreadCount: 3 4 overflowAction: throw_exception 5 retryMaxInterval: "300s" 6 retryType: periodic 7 retryWait: 1s 8 totalLimitSize: 32m 9 ...- 1
- 各チャンクの最大サイズを指定してから、フラッシュ用にキューに入れます。
- 2
- チャンクのフラッシュの間隔を指定します。
- 3
- チャンクのフラッシュを実行する方法を指定します (
lazy、interval、またはimmediate)。 - 4
- チャンクのフラッシュに使用するスレッドの数を指定します。
- 5
- キューが一杯になる場合のチャンクの動作を指定します (
throw_exception、block、またはdrop_oldest_chunk)。 - 6
exponential_backoffチャンクのフラッシュ方法について最大の間隔 (秒単位) を指定します。- 7
- チャンクのフラッシュが失敗する場合の再試行タイプ (
exponential_backoffまたはperiodic) を指定します。 - 8
- 次のチャンクのフラッシュまでの時間 (秒単位) を指定します。
- 9
- チャンクバッファーの最大サイズを指定します。
Flunentd Pod が再デプロイされていることを確認します。
$ oc get pods -l component=collector -n openshift-logging
新規の値が
fluentd設定マップにあることを確認します。$ oc extract configmap/fluentd --confirm
fluentd.conf の例
<buffer> @type file path '/var/lib/fluentd/default' flush_mode interval flush_interval 5s flush_thread_count 3 retry_type periodic retry_wait 1s retry_max_interval 300s retry_timeout 60m queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}" total_limit_size 32m chunk_limit_size 8m overflow_action throw_exception </buffer>
3.2.4.2.5. デフォルトの Elasticsearch ログストアを使用しない場合の未使用のコンポーネントの削除
管理者がログをサードパーティーのログストアに転送し、デフォルトの Elasticsearch ログストアを使用しない場合は、ロギングクラスターからいくつかの未使用のコンポーネントを削除できます。
つまり、デフォルトの Elasticsearch ログストアを使用しない場合は、内部 Elasticsearch logStore、Kibana visualization コンポーネントを ClusterLogging カスタムリソース (CR) から削除できます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。
前提条件
ログフォワーダーがログデータをデフォルトの内部 Elasticsearch クラスターに送信しないことを確認します。ログ転送の設定に使用した
ClusterLogForwarderCR YAML ファイルを検査します。これにはdefaultを指定するoutputRefs要素が ない ことを確認します。以下に例を示します。outputRefs: - default
ClusterLogForwarder CR がログデータを内部 Elasticsearch クラスターに転送し、ClusterLogging CR から logStore コンポーネントを削除するとします。この場合、内部 Elasticsearch クラスターはログデータを保存するために表示されません。これがないと、データが失われる可能性があります。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
-
これらが存在する場合は、
logStore、visualizationスタンザをClusterLoggingCR から削除します。 ClusterLoggingCR のcollectionスタンザを保持します。結果は以下の例のようになります。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" collection: logs: type: "fluentd" fluentd: {}コレクター Pod が再デプロイされたことを確認します。
$ oc get pods -l component=collector -n openshift-logging
関連情報
3.2.4.3. ログストアの設定
Red Hat OpenShift のロギングサブシステムは、Elasticsearch 6 (ES) を使用してログデータを保存および整理します。
ログストアに加えることのできる変更には、以下が含まれます。
- Elasticsearch クラスターのストレージ。
- シャードをクラスター内の複数のデータノードにレプリケートする方法 (完全なレプリケーションからレプリケーションなしまで)。
- Elasticsearch データへの外部アクセス
Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、ClusterLogging カスタムリソースで指定しない限り、メモリー要求および制限の両方に 16G 以上のメモリーが必要です。初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリー (各 Elasticsearch ノードに最大 64G) を使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。
各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境には推奨されません。
3.2.4.3.1. 監査ログのログストアへの転送
デフォルトで、OpenShift Logging では監査ログを内部の OpenShift Container Platform Elasticsearch ログストアに保存しません。Kibana で表示するなど、監査ログをこのログストアに送信できます。
監査ログをデフォルトの内部 Elasticsearch ログストアに送信するには、Kibana で監査ログを表示するなど、ログ転送 API を使用する必要があります。
内部 OpenShift Container Platform Elasticsearch ログストアは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に適合し、適切にセキュリティーが保護されていることを確認します。Red Hat OpenShift のロギングサブシステムは、これらの規制に準拠していません。
手順
ログ転送 API を使用して監査ログを内部 Elasticsearch インスタンスに転送するには、以下を実行します。
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。すべてのログタイプを内部 Elasticsearch インスタンスに送信するために CR を作成します。変更せずに以下の例を使用できます。
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: pipelines: 1 - name: all-to-default inputRefs: - infrastructure - application - audit outputRefs: - default- 1
- パイプラインは、指定された出力を使用して転送するログのタイプを定義します。デフォルトの出力は、ログを内部 Elasticsearch インスタンスに転送します。
注記パイプラインの 3 つのすべてのタイプのログをパイプラインに指定する必要があります (アプリケーション、インフラストラクチャー、および監査)。ログの種類を指定しない場合、それらのログは保存されず、失われます。
既存の
ClusterLogForwarderCR がある場合は、パイプラインを監査ログのデフォルト出力に追加します。デフォルトの出力を定義する必要はありません。以下に例を示します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: elasticsearch-insecure type: "elasticsearch" url: http://elasticsearch-insecure.messaging.svc.cluster.local insecure: true - name: elasticsearch-secure type: "elasticsearch" url: https://elasticsearch-secure.messaging.svc.cluster.local secret: name: es-audit - name: secureforward-offcluster type: "fluentdForward" url: https://secureforward.offcluster.com:24224 secret: name: secureforward pipelines: - name: container-logs inputRefs: - application outputRefs: - secureforward-offcluster - name: infra-logs inputRefs: - infrastructure outputRefs: - elasticsearch-insecure - name: audit-logs inputRefs: - audit outputRefs: - elasticsearch-secure - default 1- 1
- このパイプラインは、外部インスタンスに加えて監査ログを内部 Elasticsearch インスタンスに送信します。
関連情報
- ログ転送 API の詳細は、Forwarding logs using the Log Forwarding API を参照してください。
3.2.4.3.2. ログ保持時間の設定
デフォルトの Elasticsearch ログストアがインフラストラクチャーログ、アプリケーションログ、監査ログなどの 3 つのログソースのインデックスを保持する期間を指定する 保持ポリシー を設定できます。
保持ポリシーを設定するには、ClusterLogging カスタムリソース (CR) に各ログソースの maxAge パラメーターを設定します。CR はこれらの値を Elasticsearch ロールオーバースケジュールに適用し、Elasticsearch がロールオーバーインデックスを削除するタイミングを決定します。
Elasticsearch はインデックスをロールオーバーし、インデックスが以下の条件のいずれかに一致する場合に現在のインデックスを移動し、新規インデックスを作成します。
-
インデックスは
ElasticsearchCR のrollover.maxAgeの値よりも古い値になります。 - インデックスサイズは、40 GB x プライマリーシャードの数よりも大きくなります。
- インデックスの doc 数は、40960 KB × プライマリーシャードの数よりも大きくなります。
Elasticsearch は、設定する保持ポリシーに基づいてロールオーバーインデックスを削除します。ログソースの保持ポリシーを作成しない場合、ログはデフォルトで 7 日後に削除されます。
前提条件
- Red HatOpenShift のロギングサブシステムと OpenShift Elasticsearch Operator がインストールされている必要があります。
手順
ログの保持時間を設定するには、以下を実行します。
ClusterLoggingCR を編集して、retentionPolicyパラメーターを追加するか、変更します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" ... spec: managementState: "Managed" logStore: type: "elasticsearch" retentionPolicy: 1 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 ...- 1
- Elasticsearch が各ログソースを保持する時間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、1 日の場合は
1dになります。maxAgeよりも古いログは削除されます。デフォルトで、ログは 7 日間保持されます。
Elasticsearchカスタムリソース (CR) で設定を確認できます。たとえば、Red Hat OpenShift Logging Operator は以下の
ElasticsearchCR を更新し、8 時間ごとにインフラストラクチャーログのアクティブなインデックスをロールオーバーし、ロールオーバーされたインデックスはロールオーバーの 7 日後に削除される設定を含む保持ポリシーを設定するとします。OpenShift Container Platform は 15 分ごとにチェックし、インデックスをロールオーバーする必要があるかどうかを判別します。apiVersion: "logging.openshift.io/v1" kind: "Elasticsearch" metadata: name: "elasticsearch" spec: ... indexManagement: policies: 1 - name: infra-policy phases: delete: minAge: 7d 2 hot: actions: rollover: maxAge: 8h 3 pollInterval: 15m 4 ...- 1
- 各ログソースについて、保持ポリシーは、そのソースのログを削除/ロールオーバーするタイミングを示します。
- 2
- OpenShift Container Platform がロールオーバーされたインデックスを削除する場合。この設定は、
ClusterLoggingCR に設定するmaxAgeになります。 - 3
- インデックスをロールオーバーする際に考慮する OpenShift Container Platform のインデックス期間。この値は、
ClusterLoggingCR に設定するmaxAgeに基づいて決定されます。 - 4
- OpenShift Container Platform がインデックスをロールオーバーする必要があるかどうかをチェックする場合。この設定はデフォルトであるため、変更できません。
注記ElasticsearchCR の変更はサポートされていません。保持ポリシーに対するすべての変更はClusterLoggingCR で行う必要があります。OpenShift Elasticsearch Operator は cron ジョブをデプロイし、
pollIntervalを使用してスケジュールされる定義されたポリシーを使用して各マッピングのインデックスをロールオーバーします。$ oc get cronjob
出力例
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE elasticsearch-im-app */15 * * * * False 0 <none> 4s elasticsearch-im-audit */15 * * * * False 0 <none> 4s elasticsearch-im-infra */15 * * * * False 0 <none> 4s
3.2.4.3.3. ログストアの CPU およびメモリー要求の設定
それぞれのコンポーネント仕様は、CPU とメモリー要求の両方への調整を許可します。OpenShift Elasticsearch Operator は環境に適した値を設定するため、これらの値を手動で調整する必要はありません。
大規模なクラスターでは、Elasticsearch プロキシーコンテナーのデフォルトのメモリー制限が不十分な場合があり、これにより、プロキシーコンテナーが OOM による強制終了 (OOMKilled) が生じます。この問題が発生した場合は、Elasticsearch プロキシーのメモリー要求および制限を引き上げます。
各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨 されていません。実稼働環境で使用する場合は、デフォルトの 16Gi よりも小さい値を各 Pod に割り当てることはできません。Pod ごとに割り当て可能な最大値は 64Gi であり、この範囲の中で、できるだけ多くのメモリーを割り当てることを推奨します。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch:1 resources: limits: 2 memory: "32Gi" requests: 3 cpu: "1" memory: "16Gi" proxy: 4 resources: limits: memory: 100Mi requests: memory: 100Mi- 1
- 必要に応じて CPU およびメモリー要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は
16Giであり、CPU 要求の場合は1です。 - 2
- Pod が使用できるリソースの最大量。
- 3
- Pod のスケジュールに必要最小限のリソース。
- 4
- 必要に応じて Elasticsearch プロキシーの CPU およびメモリーの制限および要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるます。デフォルト値は、メモリー要求の場合は
256Mi、CPU 要求の場合は100mです。
Elasticsearch メモリーの量を調整するときは、要求 と 制限 の両方に同じ値を使用する必要があります。
以下に例を示します。
resources:
limits: 1
memory: "32Gi"
requests: 2
cpu: "8"
memory: "32Gi"
Kubernetes は一般的にはノードの設定に従い、Elasticsearch が指定された制限を使用することを許可しません。requests と limits に同じ値を設定することにより、Elasticseach が必要なメモリーを確実に使用できるようにします (利用可能なメモリーがノードにあることを前提とします)。
3.2.4.3.4. ログストアのレプリケーションポリシーの設定
Elasticsearch シャードをクラスター内の複数のデータノードにレプリケートする方法を定義できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit clusterlogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch: redundancyPolicy: "SingleRedundancy" 1- 1
- シャードの冗長性ポリシーを指定します。変更の保存時に変更が適用されます。
- FullRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをすべてのデータノードに完全にレプリケートします。これは最高レベルの安全性を提供しますが、最大量のディスクが必要となり、パフォーマンスは最低レベルになります。
- MultipleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをデータノードの半分に完全にレプリケートします。これは、安全性とパフォーマンス間の適切なトレードオフを提供します。
- SingleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードのコピーを 1 つ作成します。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。5 以上のノードを使用する場合は、MultipleRedundancy よりもパフォーマンスが良くなります。このポリシーは、単一 Elasticsearch ノードのデプロイメントには適用できません。
- ZeroRedundancy:Elasticsearch は、プライマリーシャードのコピーを作成しません。ノードが停止または失敗した場合は、ログは利用不可となるか、失われる可能性があります。安全性よりもパフォーマンスを重視する場合や、独自のディスク/PVC バックアップ/復元ストラテジーを実装している場合は、このモードを使用できます。
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
3.2.4.3.5. Elasticsearch Pod のスケールダウン
クラスター内の Elasticsearch Pod 数を減らすと、データ損失や Elasticsearch のパフォーマンスが低下する可能性があります。
スケールダウンする場合は、一度に 1 つの Pod 分スケールダウンし、クラスターがシャードおよびレプリカのリバランスを実行できるようにする必要があります。Elasticsearch のヘルスステータスが green に戻された後に、別の Pod でスケールダウンできます。
Elasticsearch クラスターが ZeroRedundancy に設定される場合は、Elasticsearch Pod をスケールダウンしないでください。
3.2.4.3.6. ログストアの永続ストレージの設定
Elasticsearch には永続ストレージが必要です。ストレージが高速になると、Elasticsearch のパフォーマンスも高速になります。
NFS ストレージをボリュームまたは永続ボリュームを使用 (または Gluster などの NAS を使用する) ことは Elasticsearch ストレージではサポートされません。Lucene は NFS が指定しないファイルシステムの動作に依存するためです。データの破損およびその他の問題が発生する可能性があります。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
ClusterLoggingCR を編集してクラスターの各データノードが永続ボリューム要求 (PVC) にバインドされるように指定します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" # ... spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
この例では、クラスターの各データノードが、200G の AWS General Purpose SSD (gp2) ストレージを要求する永続ボリューム要求 (PVC) にバインドされるように指定します。
永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。
3.2.4.3.7. emptyDir ストレージのログストアの設定
ログストアで emptyDir を使用できます。これは、Pod のデータすべてが再起動時に失われる一時デプロイメントを作成します。
emptyDir を使用する場合は、ログストアが再起動するか、再デプロイされる場合にデータが失われます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
ClusterLoggingCR を編集して emptyDir を指定します。spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
3.2.4.3.8. Elasticsearch クラスターのローリング再起動の実行
elasticsearch 設定マップまたは elasticsearch-* デプロイメント設定のいずれかを変更する際にローリング再起動を実行します。
さらにローリング再起動は、Elasticsearch Pod が実行されるノードで再起動が必要な場合に推奨されます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
クラスターのローリング再起動を実行するには、以下を実行します。
openshift-loggingプロジェクトに切り替えます。$ oc project openshift-logging
Elasticsearch Pod の名前を取得します。
$ oc get pods -l component=elasticsearch-
コレクター Pod をスケールダウンして、Elasticsearch への新しいログの送信を停止します。
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'OpenShift Container Platform es_util ツールを使用してシャードの同期フラッシュを実行して、シャットダウンの前にディスクへの書き込みを待機している保留中の操作がないようにします。
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST
以下に例を示します。
$ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_flush/synced" -XPOST
出力例
{"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}OpenShift Container Platform es_util ツールを使用して、ノードを意図的に停止する際のシャードのバランシングを防ぎます。
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'以下に例を示します。
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'出力例
{"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":コマンドが完了したら、ES クラスターのそれぞれのデプロイメントについて、以下を実行します。
デフォルトで、OpenShift Container Platform Elasticsearch クラスターはノードのロールアウトをブロックします。以下のコマンドを使用してロールアウトを許可し、Pod が変更を取得できるようにします。
$ oc rollout resume deployment/<deployment-name>
以下に例を示します。
$ oc rollout resume deployment/elasticsearch-cdm-0-1
出力例
deployment.extensions/elasticsearch-cdm-0-1 resumed
新規 Pod がデプロイされます。Pod に準備状態のコンテナーがある場合は、次のデプロイメントに進むことができます。
$ oc get pods -l component=elasticsearch-
出力例
NAME READY STATUS RESTARTS AGE elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr 2/2 Running 0 22h
デプロイメントが完了したら、ロールアウトを許可しないように Pod をリセットします。
$ oc rollout pause deployment/<deployment-name>
以下に例を示します。
$ oc rollout pause deployment/elasticsearch-cdm-0-1
出力例
deployment.extensions/elasticsearch-cdm-0-1 paused
Elasticsearch クラスターが
greenまたはyellow状態にあることを確認します。$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
注記直前のコマンドで使用した Elasticsearch Pod でロールアウトを実行した場合、Pod は存在しなくなっているため、ここで新規 Pod 名が必要になります。
以下に例を示します。
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
{ "cluster_name" : "elasticsearch", "status" : "yellow", 1 "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 3, "active_primary_shards" : 8, "active_shards" : 16, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 1, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 }- 1
- 次に進む前に、このパラメーターが
greenまたはyellowであることを確認します。
- Elasticsearch 設定マップを変更した場合は、それぞれの Elasticsearch Pod に対してこれらの手順を繰り返します。
クラスターのすべてのデプロイメントがロールアウトされたら、シャードのバランシングを再度有効にします。
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'以下に例を示します。
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'出力例
{ "acknowledged" : true, "persistent" : { }, "transient" : { "cluster" : { "routing" : { "allocation" : { "enable" : "all" } } } } }新しいログが Elasticsearch に送信されるように、コレクター Pod をスケールアップします。
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'
3.2.4.3.9. ログストアサービスのルートとしての公開
デフォルトでは、Red Hat OpenShift のロギングサブシステムとともにデプロイされているログストアには、ロギングクラスターの外部からアクセスできません。データにアクセスするツールについては、ログストアへの外部アクセスのために re-encryption termination でルートを有効にすることができます。
re-encrypt ルート、OpenShift Container Platform トークンおよびインストールされたログストア CA 証明書を作成して、ログストアに外部からアクセスすることができます。次に、以下を含む cURL 要求でログストアサービスをホストするノードにアクセスします。
-
Authorization: Bearer ${token} - Elasticsearch reencrypt ルートおよび Elasticsearch API 要求
内部からは、ログストアクラスター IP を使用してログストアサービスにアクセスできます。これは、以下のコマンドのいずれかを使用して取得できます。
$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging出力例
172.30.183.229
$ oc get service elasticsearch -n openshift-logging
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE elasticsearch ClusterIP 172.30.183.229 <none> 9200/TCP 22h
以下のようなコマンドを使用して、クラスター IP アドレスを確認できます。
$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"出力例
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29 100 29 0 0 108 0 --:--:-- --:--:-- --:--:-- 108
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
- ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。
手順
ログストアを外部に公開するには、以下を実行します。
openshift-loggingプロジェクトに切り替えます。$ oc project openshift-logging
ログストアから CA 証明書を抽出し、admin-ca ファイルに書き込みます。
$ oc extract secret/elasticsearch --to=. --keys=admin-ca
出力例
admin-ca
ログストアサービスのルートを YAML ファイルとして作成します。
以下のように YAML ファイルを作成します。
apiVersion: route.openshift.io/v1 kind: Route metadata: name: elasticsearch namespace: openshift-logging spec: host: to: kind: Service name: elasticsearch tls: termination: reencrypt destinationCACertificate: | 1- 1
- 次の手順でログストア CA 証明書を追加するか、コマンドを使用します。一部の re-encrypt ルートで必要とされる
spec.tls.key、spec.tls.certificate、およびspec.tls.caCertificateパラメーターを設定する必要はありません。
以下のコマンドを実行して、前のステップで作成したルート YAML にログストア CA 証明書を追加します。
$ cat ./admin-ca | sed -e "s/^/ /" >> <file-name>.yaml
ルートを作成します。
$ oc create -f <file-name>.yaml
出力例
route.route.openshift.io/elasticsearch created
Elasticsearch サービスが公開されていることを確認します。
要求に使用されるこのサービスアカウントのトークンを取得します。
$ token=$(oc whoami -t)
作成した elasticsearch ルートを環境変数として設定します。
$ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`ルートが正常に作成されていることを確認するには、公開されたルート経由で Elasticsearch にアクセスする以下のコマンドを実行します。
curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"以下のような出力が表示されます。
出力例
{ "name" : "elasticsearch-cdm-i40ktba0-1", "cluster_name" : "elasticsearch", "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ", "version" : { "number" : "6.8.1", "build_flavor" : "oss", "build_type" : "zip", "build_hash" : "Unknown", "build_date" : "Unknown", "build_snapshot" : true, "lucene_version" : "7.7.0", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "<tagline>" : "<for search>" }
3.2.4.4. ログビジュアライザーの設定
OpenShift Container Platform は、Kibana を使用して、ロギングサブシステムによって収集されたログデータを表示します。
冗長性を確保するために Kibana をスケーリングし、Kibana ノードの CPU およびメモリーを設定することができます。
3.2.4.4.1. CPU およびメモリー制限の設定
ロギングサブシステムコンポーネントを使用すると、CPU とメモリーの両方の制限を調整できます。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: 1 limits: memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: 2 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources: 3 limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 collection: logs: type: "fluentd" fluentd: resources: 4 limits: memory: 736Mi requests: cpu: 200m memory: 736Mi
3.2.4.4.2. ログビジュアライザーノードの冗長性のスケーリング
冗長性を確保するために、ログビジュアライザーをホストする Pod をスケーリングできます。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
$ oc edit ClusterLogging instance apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: visualization: type: "kibana" kibana: replicas: 1 1- 1
- Kibana ノードの数を指定します。
3.2.4.5. ロギングサブシステムストレージの設定
Elasticsearch はメモリー集約型アプリケーションです。デフォルトのロギングサブシステムのインストールでは、メモリー要求とメモリー制限の両方に 16G のメモリーがデプロイされます。初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリーを使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境には推奨されません。
3.2.4.5.1. Red Hat OpenShift のロギングサブシステムのストレージに関する考慮事項
永続ボリュームがそれぞれの Elasticsearch デプロイメント設定に必要です。OpenShift Container Platform では、これは永続ボリューム要求 (PVC) を使用して実行されます。
永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。
OpenShift Elasticsearch Operator は Elasticsearch リソース名を使用して PVC に名前を付けます。
Fluentd は systemd ジャーナル および /var/log/containers/ から Elasticsearch にログを送信します。
Elasticsearch では、大規模なマージ操作を実行するのに十分なメモリーが必要です。十分なメモリーがない場合は、応答しなくなります。この問題を回避するには、必要なアプリケーションのログデータの量を評価し、空き容量の約 2 倍を割り当てます。
デフォルトで、ストレージ容量が 85% に達すると、Elasticsearch は新規データのノードへの割り当てを停止します。90% になると、Elasticsearch は可能な場合に既存のシャードをそのノードから他のノードに移動しようとします。ただし、空き容量のレベルが 85% 未満のノードがない場合、Elasticsearch は新規インデックスの作成を拒否し、ステータスは RED になります。
これらの基準値 (高い値および低い値を含む) は現行リリースにおける Elasticsearch のデフォルト値です。これらのデフォルト値は変更できます。アラートは同じデフォルト値を使用しますが、これらの値をアラートで変更することはできません。
3.2.4.5.2. 関連情報
3.2.4.6. ロギングサブシステムコンポーネントの CPU およびメモリー制限の設定
必要に応じて、ロギングサブシステムコンポーネントごとに CPU とメモリーの両方の制限を設定できます。
3.2.4.6.1. CPU およびメモリー制限の設定
ロギングサブシステムコンポーネントを使用すると、CPU とメモリーの両方の制限を調整できます。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: 1 limits: memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: 2 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources: 3 limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 collection: logs: type: "fluentd" fluentd: resources: 4 limits: memory: 736Mi requests: cpu: 200m memory: 736Mi
3.2.4.7. 容認を使用した OpenShift Logging Pod 配置の制御
taint と toleration を使用することで、ロギングシステム pod が特定のノードで実行され、その他のワークロードがそれらのノードで実行されないようにします。
テイントおよび容認は、単純な key:value のペアです。ノードのテイントはノードに対し、テイントを容認しないすべての Pod を拒否するよう指示します。
key は最大 253 文字までの文字列で、value は最大 63 文字までの文字列になります。文字列は文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。
toleration のあるサンプルロギングサブシステム CR
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: openshift-logging
...
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
tolerations: 1
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 16Gi
requests:
cpu: 200m
memory: 16Gi
storage: {}
redundancyPolicy: "ZeroRedundancy"
visualization:
type: "kibana"
kibana:
tolerations: 2
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 2Gi
requests:
cpu: 100m
memory: 1Gi
replicas: 1
collection:
logs:
type: "fluentd"
fluentd:
tolerations: 3
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 2Gi
requests:
cpu: 100m
memory: 1Gi
3.2.4.7.1. 容認を使用したログストア Pod の配置の制御
ログストア Pod が実行するノードを制御し、Pod の容認を使用して他のワークロードがそれらのノードを使用しないようにできます。
ClusterLogging カスタムリソース (CR) を使用して容認をログストア Pod に適用し、テイントをノード仕様でノードに適用します。ノードのテイントは、テイントを容認しないすべての Pod を拒否するようノードに指示する key:value pair です。他の Pod にはない特定の key:value ペアを使用することで、ログストア Pod のみがそのノード上で実行されるようにできます。
デフォルトで、ログストア Pod には以下の容認があります。
tolerations: - effect: "NoExecute" key: "node.kubernetes.io/disk-pressure" operator: "Exists"
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
以下のコマンドを使用して、OpenShift Logging Pod をスケジュールするノードにテイントを追加します。
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
以下に例を示します。
$ oc adm taint nodes node1 elasticsearch=node:NoExecute
この例では、テイントをキー
elasticsearch、値node、およびテイントの効果NoExecuteのあるnode1に配置します。NoExecuteeffect のノードは、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。ClusterLoggingCR のlogstoreセクションを編集し、Elasticsearch Pod の容認を設定します。logStore: type: "elasticsearch" elasticsearch: nodeCount: 1 tolerations: - key: "elasticsearch" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は node1 にスケジュールできます。
3.2.4.7.2. 容認を使用したログビジュアライザー Pod の配置の制御
ログビジュアライザー Pod が実行されるノードを制御し、Pod の容認を使用して他のワークロードがそれらのノードを使用しないようにできます。
ClusterLogging カスタムリソース (CR) を使用して容認をログビジュアライザー Pod に適用し、テイントをノード仕様でノードに適用します。ノードのテイントは、テイントを容認しないすべての Pod を拒否するようノードに指示する key:value pair です。他の Pod にはない特定の key:value ペアを使用することで、Kibana Pod のみをそのノード上で実行できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
以下のコマンドを使用して、ログビジュアライザー Pod をスケジュールする必要のあるノードにテイントを追加します。
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
以下に例を示します。
$ oc adm taint nodes node1 kibana=node:NoExecute
この例では、テイントをキー
kibana、値node、およびテイントの効果NoExecuteのあるnode1に配置します。NoExecuteテイント effect を使用する必要があります。NoExecuteは、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。ClusterLoggingCR のvisualizationセクションを編集し、Kibana Pod の容認を設定します。visualization: type: "kibana" kibana: tolerations: - key: "kibana" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は、node1 にスケジュールできます。
3.2.4.7.3. 容認を使用したログコレクター Pod 配置の制御
ロギングコレクター Pod が実行するノードを確認し、Pod の容認を使用して他のワークロードがそれらのノードを使用しないようにできます。
容認を ClusterLogging カスタムリソース (CR) でロギングコレクター Pod に適用し、テイントをノード仕様でノードに適用します。テイントおよび容認を使用すると、Pod がメモリーや CPU などの問題によってエビクトされないようにできます。
デフォルトで、ロギングコレクター Pod には以下の容認があります。
tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoExecute"
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
以下のコマンドを使用して、ロギングコレクター Pod がロギングコレクター Pod をスケジュールする必要のあるノードにテイントを追加します。
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
以下に例を示します。
$ oc adm taint nodes node1 collector=node:NoExecute
この例では、テイントをキー
collector、値node、およびテイント effectNoExecuteのあるnode1に配置します。NoExecuteテイント effect を使用する必要があります。NoExecuteは、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。ClusterLoggingカスタムリソース (CR) のcollectionスタンザを編集して、ロギングコレクター Pod の容認を設定します。collection: logs: type: "fluentd" fluentd: tolerations: - key: "collector" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は、node1 にスケジュールできます。
3.2.4.7.4. 関連情報
3.2.4.8. ノードセレクターを使用したロギングサブシステムリソースの移動
ノードセレクターを使用して Elasticsearch、Kibana Pod を異なるノードにデプロイできます。
3.2.4.8.1. OpenShift Logging リソースの移動
Elasticsearch および Kibana などのロギングシステムコンポーネントの pod を異なるノードにデプロイするように Cluster Logging Operator を設定できます。Cluster Logging Operator Pod をインストールした場所から移動することはできません。
たとえば、Elasticsearch Pod の CPU、メモリーおよびディスクの要件が高いために、この Pod を別のノードに移動できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。これらの機能はデフォルトでインストールされません。
手順
openshift-loggingプロジェクトでClusterLoggingカスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
apiVersion: logging.openshift.io/v1 kind: ClusterLogging ... spec: collection: logs: fluentd: resources: null type: fluentd logStore: elasticsearch: nodeCount: 3 nodeSelector: 1 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved redundancyPolicy: SingleRedundancy resources: limits: cpu: 500m memory: 16Gi requests: cpu: 500m memory: 16Gi storage: {} type: elasticsearch managementState: Managed visualization: kibana: nodeSelector: 2 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved proxy: resources: null replicas: 1 resources: null type: kibana ...
検証
コンポーネントが移動したことを確認するには、oc get pod -o wide コマンドを使用できます。
以下に例を示します。
Kibana Pod を
ip-10-0-147-79.us-east-2.compute.internalノードから移動する必要がある場合は、以下を実行します。$ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-5b8bdf44f9-ccpq9 2/2 Running 0 27s 10.129.2.18 ip-10-0-147-79.us-east-2.compute.internal <none> <none>
Kibana Pod を、専用インフラストラクチャーノードである
ip-10-0-139-48.us-east-2.compute.internalノードに移動する必要がある場合は、以下を実行します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-133-216.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-146.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-192.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-139-241.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-147-79.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-152-241.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-48.us-east-2.compute.internal Ready infra 51m v1.24.0
ノードには
node-role.kubernetes.io/infra: ''ラベルがあることに注意してください。$ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml
出力例
kind: Node apiVersion: v1 metadata: name: ip-10-0-139-48.us-east-2.compute.internal selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751 resourceVersion: '39083' creationTimestamp: '2020-04-13T19:07:55Z' labels: node-role.kubernetes.io/infra: '' ...Kibana Pod を移動するには、
ClusterLoggingCR を編集してノードセレクターを追加します。apiVersion: logging.openshift.io/v1 kind: ClusterLogging ... spec: ... visualization: kibana: nodeSelector: 1 node-role.kubernetes.io/infra: '' proxy: resources: null replicas: 1 resources: null type: kibana- 1
- ノード仕様のラベルに一致するノードセレクターを追加します。
CR を保存した後に、現在の Kibana Pod は終了し、新規 Pod がデプロイされます。
$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 29m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 28m fluentd-42dzz 1/1 Running 0 28m fluentd-d74rq 1/1 Running 0 28m fluentd-m5vr9 1/1 Running 0 28m fluentd-nkxl7 1/1 Running 0 28m fluentd-pdvqb 1/1 Running 0 28m fluentd-tflh6 1/1 Running 0 28m kibana-5b8bdf44f9-ccpq9 2/2 Terminating 0 4m11s kibana-7d85dcffc8-bfpfp 2/2 Running 0 33s
新規 Pod が
ip-10-0-139-48.us-east-2.compute.internalノードに置かれます。$ oc get pod kibana-7d85dcffc8-bfpfp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-7d85dcffc8-bfpfp 2/2 Running 0 43s 10.131.0.22 ip-10-0-139-48.us-east-2.compute.internal <none> <none>
しばらくすると、元の Kibana Pod が削除されます。
$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 30m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 29m fluentd-42dzz 1/1 Running 0 29m fluentd-d74rq 1/1 Running 0 29m fluentd-m5vr9 1/1 Running 0 29m fluentd-nkxl7 1/1 Running 0 29m fluentd-pdvqb 1/1 Running 0 29m fluentd-tflh6 1/1 Running 0 29m kibana-7d85dcffc8-bfpfp 2/2 Running 0 62s
3.2.4.9. systemd-journald および Fluentd の設定
Fluentd のジャーナルからの読み取りや、ジャーナルのデフォルト設定値は非常に低く、ジャーナルがシステムサービスからのロギング速度に付いていくことができないためにジャーナルエントリーが失われる可能性があります。
ジャーナルでエントリーが失われるのを防ぐことができるように RateLimitIntervalSec=30s および RateLimitBurst=10000 (必要な場合はさらに高い値) を設定することが推奨されます。
3.2.4.9.1. OpenShift Logging 用の systemd-journald の設定
プロジェクトのスケールアップ時に、デフォルトのロギング環境にはいくらかの調整が必要になる場合があります。
たとえば、ログが見つからない場合は、journald の速度制限を引き上げる必要がある場合があります。一定期間保持するメッセージ数を調整して、OpenShift Logging がログをドロップせずに過剰なリソースを使用しないようにすることができます。
また、ログを圧縮する必要があるかどうか、ログを保持する期間、ログを保存する方法、ログを保存するかどうかやその他の設定を決定することもできます。
手順
必要な設定で
/etc/systemd/journald.confファイルが含まれる Butane 設定ファイル40-worker-custom -journald.buを作成します。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
variant: openshift version: 4.11.0 metadata: name: 40-worker-custom-journald labels: machineconfiguration.openshift.io/role: "worker" storage: files: - path: /etc/systemd/journald.conf mode: 0644 1 overwrite: true contents: inline: | Compress=yes 2 ForwardToConsole=no 3 ForwardToSyslog=no MaxRetentionSec=1month 4 RateLimitBurst=10000 5 RateLimitIntervalSec=30s Storage=persistent 6 SyncIntervalSec=1s 7 SystemMaxUse=8G 8 SystemKeepFree=20% 9 SystemMaxFileSize=10M 10- 1
journal.confファイルのパーミッションを設定します。0644パーミッションを設定することが推奨されます。- 2
- ログがファイルシステムに書き込まれる前にそれらのログを圧縮するかどうかを指定します。
yesを指定してメッセージを圧縮するか、noを指定して圧縮しないようにします。デフォルトはyesです。 - 3
- ログメッセージを転送するかどうかを設定します。それぞれについて、デフォルトで
noに設定されます。以下を指定します。-
ForwardToConsole: ログをシステムコンソールに転送します。 -
ForwardToKsmg: ログをカーネルログバッファーに転送します。 -
ForwardToSyslog: syslog デーモンに転送します。 -
ForwardToWall: メッセージを wall メッセージとしてすべてのログインしているユーザーに転送します。
-
- 4
- ジャーナルエントリーを保存する最大時間を指定します。数字を入力して秒数を指定します。または、year、month、week、day、h または m などの単位を含めます。無効にするには
0を入力します。デフォルトは1monthです。 - 5
- レート制限を設定します。
RateLimitIntervalSecで定義される期間に、RateLimitBurstで指定される以上のログが受信される場合、この期間内の追加のメッセージはすべてこの期間が終了するまでにドロップされます。デフォルト値であるRateLimitIntervalSec=30sおよびRateLimitBurst=10000を設定することが推奨されます。 - 6
- ログの保存方法を指定します。デフォルトは
persistentです。-
volatile: ログを/var/log/journal/のメモリーに保存します。 -
persistent: ログを/var/log/journal/のディスクに保存します。systemd は存在しない場合はディレクトリーを作成します。 -
auto: ディレクトリーが存在する場合に、ログを/var/log/journal/に保存します。存在しない場合は、systemd はログを/run/systemd/journalに一時的に保存します。 -
none: ログを保存しません。systemd はすべてのログをドロップします。
-
- 7
- ERR、WARNING、NOTICE、INFO、および DEBUG ログについてジャーナルファイルをディスクに同期させるまでのタイムアウトを指定します。 systemd は、CRIT、ALERT、または EMERG ログの受信後すぐに同期を開始します。デフォルトは
1sです。 - 8
- ジャーナルが使用できる最大サイズを指定します。デフォルトは
8Gです。 - 9
- systemd が残す必要のあるディスク領域のサイズを指定します。デフォルトは
20%です。 - 10
/var/log/journalに永続的に保存される個別のジャーナルファイルの最大サイズを指定します。デフォルトは10Mです。注記レート制限を削除する場合、システムロギングデーモンの CPU 使用率が高くなることがあります。 以前はスロットリングされていた可能性のあるメッセージが処理されるためです。
systemd 設定の詳細については、https://www.freedesktop.org/software/systemd/man/journald.conf.html を参照してください。このページに一覧表示されるデフォルト設定は OpenShift Container Platform には適用されない可能性があります。
Butane を使用して、ノードに配信される設定を含む
MachineConfigオブジェクトファイル (40-worker-custom-journald.yaml) を生成します。$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
マシン設定を適用します。以下に例を示します。
$ oc apply -f 40-worker-custom-journald.yaml
コントローラーは新規の
MachineConfigオブジェクトを検出し、新規のrendered-worker-<hash>バージョンを生成します。新規のレンダリングされた設定の各ノードへのロールアウトのステータスをモニターします。
$ oc describe machineconfigpool/worker
出力例
Name: worker Namespace: Labels: machineconfiguration.openshift.io/mco-built-in= Annotations: <none> API Version: machineconfiguration.openshift.io/v1 Kind: MachineConfigPool ... Conditions: Message: Reason: All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e
3.2.4.10. メンテナンスとサポート
3.2.4.10.1. サポートされる設定
Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。本書で説明されている設定以外の設定を使用する場合、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。
OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合、Red Hat OpenShift Logging Operator または OpenShift Elasticsearch Operator を Unmanaged (管理外) に設定する 必要があります。管理外の OpenShift Logging 環境は サポート外 であり、OpenShift Logging を Managed に戻すまで変更を受信しません。
3.2.4.10.2. サポートされない設定
以下のコンポーネントを変更するには、Red Hat OpenShift Logging Operator を Unmanaged (管理外) の状態に設定する必要があります。
-
ElasticsearchCR - Kibana デプロイメント
-
fluent.confファイル - Fluentd デーモンセット
以下のコンポーネントを変更するには、OpenShift Elasticsearch Operator を Unmanaged(管理外) の状態に設定する必要があります。
- Elasticsearch デプロイメントファイル。
明示的にサポート対象外とされているケースには、以下が含まれます。
- デフォルトのログローテーションの設定。デフォルトのログローテーション設定は変更できません。
-
収集したログの場所の設定。ログコレクターの出力ファイルの場所を変更することはできません。デフォルトは
/var/log/fluentd/fluentd.logです。 - ログコレクションのスロットリング。ログコレクターによってログが読み取られる速度を調整して減速することはできません。
- 環境変数を使用したロギングコレクターの設定。環境変数を使用してログコレクターを変更することはできません。
- ログコレクターによってログを正規化する方法の設定。デフォルトのログの正規化を変更することはできません。
3.2.4.10.3. 管理外の Operator のサポートポリシー
Operator の 管理状態 は、Operator が設計通りにクラスター内の関連するコンポーネントのリソースをアクティブに管理しているかどうかを定めます。Operator が unmanaged 状態に設定されていると、これは設定の変更に応答せず、更新を受信しません。
これは非実稼働クラスターやデバッグ時に便利ですが、管理外の状態の Operator はサポートされず、クラスター管理者は個々のコンポーネント設定およびアップグレードを完全に制御していることを前提としています。
Operator は以下の方法を使用して管理外の状態に設定できます。
個別の Operator 設定
個別の Operator には、それらの設定に
managementStateパラメーターがあります。これは Operator に応じてさまざまな方法でアクセスできます。たとえば、Red Hat OpenShift Logging Operator は管理するカスタムリソース (CR) を変更することによってこれを実行しますが、Cluster Samples Operator はクラスター全体の設定リソースを使用します。managementStateパラメーターをUnmanagedに変更する場合、Operator はそのリソースをアクティブに管理しておらず、コンポーネントに関連するアクションを取らないことを意味します。Operator によっては、クラスターが破損し、手動リカバリーが必要になる可能性があるため、この管理状態に対応しない可能性があります。警告個別の Operator を
Unmanaged状態に変更すると、特定のコンポーネントおよび機能がサポート対象外になります。サポートを継続するには、報告された問題をManaged状態で再現する必要があります。Cluster Version Operator (CVO) のオーバーライド
spec.overridesパラメーターを CVO の設定に追加すると、管理者はコンポーネントの CVO の動作に対してオーバーライドの一覧を追加できます。コンポーネントのspec.overrides[].unmanagedパラメーターをtrueに設定すると、クラスターのアップグレードがブロックされ、CVO のオーバーライドが設定された後に管理者にアラートが送信されます。Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告CVO のオーバーライドを設定すると、クラスター全体がサポートされない状態になります。サポートを継続するには、オーバーライドを削除した後に、報告された問題を再現する必要があります。
3.2.5. Loki
3.2.5.1. LokiStack
ロギングサブシステムのドキュメントでは、LokiStack はロギングサブシステムでサポートされている Loki と Web プロキシーと OpenShift Container Platform 認証統合の組み合わせを指します。LokiStack のプロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用します。Loki では、ログストアを個別のコンポーネントまたは外部ストアと呼んでいます。
Loki は、水平方向にスケーラブルで可用性の高いマルチテナントログ集約システムであり、現在、ロギングサブシステムのログストアとして Elasticsearch の代替として提供されています。Elasticsearch は、取り込み中に受信ログレコードを完全にインデックス化します。Loki は、取り込み中にいくつかの固定ラベルのみをインデックスに登録し、ログが保存されるまで、より複雑な解析が延期されるのでLoki がより迅速にログを収集できるようになります。Elasticsearch と同様に、JSON パスまたは正規表現を使用して Loki にクエリーを実行できます。
3.2.5.1.1. デプロイメントのサイズ
Loki のサイズは N<x>.<size> の形式に従います。<N> はインスタンスの数を、<size> はパフォーマンスの機能を指定します。
1x.extra-small はデモ用であり、サポートされていません。
表3.9 Loki のサイズ
| 1x.extra-small | 1x.small | 1x.medium | |
|---|---|---|---|
| データ転送 | デモ使用のみ。 | 500GB/day | 2TB/日 |
| 1 秒あたりのクエリー数 (QPS) | デモ使用のみ。 | 200 ミリ秒で 25 - 50 QPS | 200 ミリ秒で 25 ~ 75 QPS |
| レプリケーション係数 | なし | 2 | 3 |
| 合計 CPU 要求 | 仮想 CPU 5 個 | 仮想 CPU 36 個 | 仮想 CPU 54 個 |
| 合計メモリー要求 | 7.5Gi | 63Gi | 139Gi |
| ディスク要求の合計 | 150Gi | 300Gi | 450Gi |
3.2.5.1.2. サポート対象の API カスタムリソース定義
LokiStack は開発中で、現在すべての API がサポートされているわけではありません。
| CustomResourceDefinition (CRD) | ApiVersion | サポートの状態 |
|---|---|---|
| LokiStack | lokistack.loki.grafana.com/v1 | 5.5 でサポート |
| RulerConfig | rulerconfig.loki.grafana/v1beta1 | テクノロジープレビュー |
| AlertingRule | alertingrule.loki.grafana/v1beta1 | テクノロジープレビュー |
| RecordingRule | recordingrule.loki.grafana/v1beta1 | テクノロジープレビュー |
RulerConfig、AlertingRule、RecordingRule カスタムリソース定義 (CRD) の使用は、テクノロジープレビュー機能のみとなっています。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.2.5.2. Lokistack のデプロイ
OpenShift Container Platform Web コンソールを使用して LokiStack をデプロイできます。
前提条件
- Red Hat OpenShift Operator 5.5 以降のロギングサブシステム
- 対応ログストア (AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation)
手順
Loki OperatorOperator をインストールします。- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
- Installation Mode で、All namespaces on the cluster を選択します。
Installed Namespace で、openshift-operators-redhat を選択します。
openshift-operators-redhatnamespace を指定する必要があります。openshift-operatorsnamespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。Enable operator recommended cluster monitoring on this namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"ラベルを設定します。クラスターモニタリングがopenshift-operators-redhatnamespace を収集できるように、このオプションを選択する必要があります。Approval Strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
- Loki Operator がインストールされていることを確認します。Operators→ Installed Operators ページにアクセスして、Loki Operator を探します。
- Loki Operator がすべてのプロジェクトで Succeeded の Status でリストされていることを確認します。
access_key_idフィールドとaccess_key_secretフィールドを使用して AWS 認証情報とbucketnames、endpoint、およびregionを指定し、オブジェクトストレージの場所を定義するSecretYAML ファイルを作成します。以下に例を示します。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
LokiStackカスタムリソースを作成します。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: size: 1x.small storage: schemas: - version: v12 effectiveDate: "2022-06-01" secret: name: logging-loki-s3 type: s3 storageClassName: gp2 tenants: mode: openshift-logging設定を適用します。
oc apply -f logging-loki.yaml
ClusterLoggingCR を作成または編集します。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設定を適用します。
oc apply -f cr-lokistack.yaml
RedHat OpenShift ログコンソールプラグインを有効にします。
- OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
- RedHat OpenShift Logging Operator を選択します。
- コンソールプラグインで 無効 をクリックします。
- 有効、保存 の順に選択します。このように変更することで、openshift-consolePod が再起動されます。
- Pod の再起動後、Web コンソールの更新が利用可能であるという通知を受け取り、更新するよう求められます。
- Web コンソールを更新したら、左側のメインメニューから 監視 をクリックします。ログ の新しいオプションが利用可能になります。
このプラグインは、OpenShift Container Platform 4.10 以降でのみ使用できます。
3.2.5.3. Loki でストリームベースの保持を有効にする
Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
-
ストリームベースの保持を有効にするには、
LokiStackカスタムリソース (CR) を作成または編集します。
oc create -f <file-name>.yaml
- 以下の例を参照して、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 クエリー が含まれています。
- 次に、設定を適用します。
oc apply -f <file-name>.yaml
これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。
3.2.5.4. ログの LokiStack への転送
LokiStack ゲートウェイへのログ転送を設定するには、ClusterLogging カスタムリソース (CR) を作成する必要があります。
前提条件
- Red Hat OpenShift のロギングサブシステム: 5.5 以降
-
Loki OperatorOperator
手順
-
ClusterLoggingカスタムリソース (CR) を定義する YAML ファイルを作成または編集します。
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: vector3.2.5.4.1. "entry out of order" エラーのトラブルシューティング
Fluentd がレート制限を超えるサイズの大きいメッセージブロックを Loki ロギングシステムに転送する場合は、Loki は "entry out of order" のエラーを生成します。この問題を修正するには、Loki サーバー設定ファイル loki.yaml のいくつかの値を更新します。
loki.yaml は、Grafana がホストする Loki では使用できません。このトピックは、Grafana がホストする Loki サーバーには適用されません。
条件
-
Cluster Log Forwarderカスタムリソースは、ログを Loki に転送するように設定されています。 システムは、次のような 2MB を超えるメッセージのブロックを Loki に送信します。
"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\ ....... ...... ...... ...... \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}oc logs -c fluentdと入力すると、OpenShift Logging クラスターの Fluentd ログに次のメッセージが表示されます。429 Too Many Requests Ingestion rate limit exceeded (limit: 8388608 bytes/sec) while attempting to ingest '2140' lines totaling '3285284' bytes 429 Too Many Requests Ingestion rate limit exceeded' or '500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5277702 vs. 4194304)'
Loki サーバーでログを開くと、次のような
entry out of orderメッセージが表示されます。,\nentry with timestamp 2021-08-18 05:58:55.061936 +0000 UTC ignored, reason: 'entry out of order' for stream: {fluentd_thread=\"flush_thread_0\", log_type=\"audit\"},\nentry with timestamp 2021-08-18 06:01:18.290229 +0000 UTC ignored, reason: 'entry out of order' for stream: {fluentd_thread="flush_thread_0", log_type="audit"}
手順
Loki サーバーの
loki.yaml設定ファイルの次のフィールドを、ここに示す値で更新します。-
grpc_server_max_recv_msg_size: 8388608 -
chunk_target_size: 8388608 -
ingestion_rate_mb: 8 -
ingestion_burst_size_mb: 16
-
-
loki.yamlの変更を Loki サーバーに適用します。
loki.yaml ファイルの例
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
grpc_server_max_recv_msg_size: 8388608
ingester:
wal:
enabled: true
dir: /tmp/wal
lifecycler:
address: 127.0.0.1
ring:
kvstore:
store: inmemory
replication_factor: 1
final_sleep: 0s
chunk_idle_period: 1h # Any chunk not receiving new logs in this time will be flushed
chunk_target_size: 8388608
max_chunk_age: 1h # All chunks will be flushed when they hit this age, default is 1h
chunk_retain_period: 30s # Must be greater than index read cache TTL if using an index cache (Default index read cache TTL is 5m)
max_transfer_retries: 0 # Chunk transfers disabled
schema_config:
configs:
- from: 2020-10-24
store: boltdb-shipper
object_store: filesystem
schema: v11
index:
prefix: index_
period: 24h
storage_config:
boltdb_shipper:
active_index_directory: /tmp/loki/boltdb-shipper-active
cache_location: /tmp/loki/boltdb-shipper-cache
cache_ttl: 24h # Can be increased for faster performance over longer query periods, uses more disk space
shared_store: filesystem
filesystem:
directory: /tmp/loki/chunks
compactor:
working_directory: /tmp/loki/boltdb-shipper-compactor
shared_store: filesystem
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 12h
ingestion_rate_mb: 8
ingestion_burst_size_mb: 16
chunk_store_config:
max_look_back_period: 0s
table_manager:
retention_deletes_enabled: false
retention_period: 0s
ruler:
storage:
type: local
local:
directory: /tmp/loki/rules
rule_path: /tmp/loki/rules-temp
alertmanager_url: http://localhost:9093
ring:
kvstore:
store: inmemory
enable_api: true
関連情報
3.2.5.5. 関連情報
3.2.6. リソースのログの表示
OpenShift CLI (oc) および Web コンソールを使用して、ビルド、デプロイメント、および Pod などの各種リソースのログを表示できます。
リソースログは、制限されたログ表示機能を提供するデフォルトの機能です。ログの取得および表示のエクスペリエンスを強化するには、OpenShift Logging をインストールすることが推奨されます。ロギングシステムは、ノードシステムの監査ログ、アプリケーションコンテナーログ、およびインフラストラクチャーログなどの OpenShift Container Platform クラスターからのすべてのログを専用のログストアに集計します。次に、Kibana interface を使用してログデータをクエリーし、検出し、可視化できます。リソースログは、ロギングサブシステムのログストアにアクセスしません。
3.2.6.1. リソースログの表示
OpenShift CLI (oc) および Web コンソールで、各種リソースのログを表示できます。ログの末尾から読み取られるログ。
前提条件
- OpenShift CLI (oc) へのアクセス。
手順 (UI)
OpenShift Container Platform コンソールで Workloads → Pods に移動するか、調査するリソースから Pod に移動します。
注記ビルドなどの一部のリソースには、直接クエリーする Pod がありません。このような場合は、リソースの Details ページで Logs リンクを特定できます。
- ドロップダウンメニューからプロジェクトを選択します。
- 調査する Pod の名前をクリックします。
- Logs をクリックします。
手順 (CLI)
特定の Pod のログを表示します。
$ oc logs -f <pod_name> -c <container_name>
ここでは、以下のようになります。
-f- オプション: ログに書き込まれている内容に沿って出力することを指定します。
<pod_name>- Pod の名前を指定します。
<container_name>- オプション: コンテナーの名前を指定します。Pod に複数のコンテナーがある場合は、コンテナー名を指定する必要があります。
以下に例を示します。
$ oc logs ruby-58cd97df55-mww7r
$ oc logs -f ruby-57f7f4855b-znl92 -c ruby
ログファイルの内容が出力されます。
特定のリソースのログを表示します。
$ oc logs <object_type>/<resource_name> 1- 1
- リソースタイプおよび名前を指定します。
以下に例を示します。
$ oc logs deployment/ruby
ログファイルの内容が出力されます。
3.2.7. Kibana を使用したクラスターログの表示
ロギングサブシステムには、収集されたログデータを視覚化するための Web コンソールが含まれています。現時点で、OpenShift Container Platform では、可視化できるように Kibana コンソールをデプロイします。
ログビジュアライザーを使用して、データで以下を実行できます。
- Discover タブを使用してデータを検索し、参照します。
- Visualize タブを使用してデータのグラフを表示し、データをマップします。
- Dashboard タブを使用してカスタムダッシュボードを作成し、表示します。
Kibana インターフェイスの使用および設定は、このドキュメントでは扱いません。詳細については、Kibana ドキュメント を参照してください。
監査ログは、デフォルトでは内部 OpenShift Container Platform Elasticsearch インスタンスに保存されません。Kibana で監査ログを表示するには、Log Forwarding API を使用して、監査ログの default 出力を使用するパイプラインを設定する必要があります。
3.2.7.1. Kibana インデックスパターンの定義
インデックスパターンは、可視化する必要のある Elasticsearch インデックスを定義します。Kibana でデータを確認し、可視化するには、インデックスパターンを作成する必要があります。
前提条件
Kibana で infra および audit インデックスを表示するには、ユーザーには
cluster-adminロール、cluster-readerロール、または両方のロールが必要です。デフォルトのkubeadminユーザーには、これらのインデックスを表示するための適切なパーミッションがあります。default、kube-およびopenshift-プロジェクトで Pod およびログを表示できる場合に、これらのインデックスにアクセスできるはずです。以下のコマンドを使用して、現在のユーザーが適切なパーミッションを持っているかどうかを確認できます。$ oc auth can-i get pods/log -n <project>
出力例
yes
注記監査ログは、デフォルトでは内部 OpenShift Container Platform Elasticsearch インスタンスに保存されません。Kibana で監査ログを表示するには、ログ転送 API を使用して監査ログの
default出力を使用するパイプラインを設定する必要があります。- Elasticsearch ドキュメントは、インデックスパターンを作成する前にインデックス化する必要があります。これは自動的に実行されますが、新規または更新されたクラスターでは数分の時間がかかる可能性があります。
手順
Kibana でインデックスパターンを定義し、ビジュアライゼーションを作成するには、以下を実行します。
-
OpenShift Container Platform コンソールで、Application Launcher
をクリックし、Logging を選択します。
Management → Index Patterns → Create index pattern をクリックして Kibana インデックスパターンを作成します。
-
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
appという名前のインデックスパターンを作成し、@timestamp時間フィールドを使用してコンテナーログを表示する必要があります。 -
管理ユーザーはそれぞれ、最初に Kibana にログインする際に、
@timestamp時間フィールドを使用してapp、infraおよびauditインデックスのインデックスパターンを作成する必要があります。
-
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
- 新規インデックスパターンから Kibana のビジュアライゼーション (Visualization) を作成します。
3.2.7.2. Kibana でのクラスターログの表示
Kibana Web コンソールでクラスターのログを表示します。Kibana でデータを表示し、可視化する方法は、このドキュメントでは扱いません。詳細は、Kibana ドキュメント を参照してください。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
- Kibana インデックスパターンが存在する。
Kibana で infra および audit インデックスを表示するには、ユーザーには
cluster-adminロール、cluster-readerロール、または両方のロールが必要です。デフォルトのkubeadminユーザーには、これらのインデックスを表示するための適切なパーミッションがあります。default、kube-およびopenshift-プロジェクトで Pod およびログを表示できる場合に、これらのインデックスにアクセスできるはずです。以下のコマンドを使用して、現在のユーザーが適切なパーミッションを持っているかどうかを確認できます。$ oc auth can-i get pods/log -n <project>
出力例
yes
注記監査ログは、デフォルトでは内部 OpenShift Container Platform Elasticsearch インスタンスに保存されません。Kibana で監査ログを表示するには、ログ転送 API を使用して監査ログの
default出力を使用するパイプラインを設定する必要があります。
手順
Kibana でログを表示するには、以下を実行します。
-
OpenShift Container Platform コンソールで、Application Launcher
をクリックし、Logging を選択します。
OpenShift Container Platform コンソールにログインするために使用するものと同じ認証情報を使用してログインします。
Kibana インターフェイスが起動します。
- Kibana で Discover をクリックします。
左上隅のドロップダウンメニューから作成したインデックスパターン (app、audit、または infra) を選択します。
ログデータは、タイムスタンプ付きのドキュメントとして表示されます。
- タイムスタンプ付きのドキュメントの 1 つを展開します。
JSON タブをクリックし、ドキュメントのログエントリーを表示します。
例3.1 Kibana のインフラストラクチャーログエントリーのサンプル
{ "_index": "infra-000001", "_type": "_doc", "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3", "_version": 1, "_score": null, "_source": { "docker": { "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1" }, "kubernetes": { "container_name": "registry-server", "namespace_name": "openshift-marketplace", "pod_name": "redhat-marketplace-n64gc", "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7", "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f", "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a", "host": "ip-10-0-182-28.us-east-2.compute.internal", "master_url": "https://kubernetes.default.svc", "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38", "namespace_labels": { "openshift_io/cluster-monitoring": "true" }, "flat_labels": [ "catalogsource_operators_coreos_com/update=redhat-marketplace" ] }, "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051", "level": "unknown", "hostname": "ip-10-0-182-28.internal", "pipeline_metadata": { "collector": { "ipaddr4": "10.0.182.28", "inputname": "fluent-plugin-systemd", "name": "fluentd", "received_at": "2020-09-23T20:47:15.007583+00:00", "version": "1.7.4 1.6.0" } }, "@timestamp": "2020-09-23T20:47:03.422465+00:00", "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3", "openshift": { "labels": { "logging": "infra" } } }, "fields": { "@timestamp": [ "2020-09-23T20:47:03.422Z" ], "pipeline_metadata.collector.received_at": [ "2020-09-23T20:47:15.007Z" ] }, "sort": [ 1600894023422 ] }
3.2.8. ログの外部のサードパーティーロギングシステムへの転送
デフォルトで、ロギングシステムは ClusterLogging カスタムリソースに定義されるデフォルトの内部ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合には、クラスターログフォワーダーを設定する必要はありません。
ログを他のログアグリゲーターに送信するには、OpenShift Container Platform クラスターログフォワーダーを使用します。この API を使用すると、コンテナー、インフラストラクチャーおよび監査ログをクラスター内外の特定のエンドポイントに送信できます。さらに、異なるタイプのログをさまざまなシステムに送信できるため、さまざまなユーザーがそれぞれのタイプにアクセスできます。また、Transport Layer Security (TLS) のサポートを有効にして、組織の要件に合わせてログを安全に送信することもできます。
監査ログをデフォルトの内部 Elasticsearch ログストアに送信するには、Forward audit logs to the log store で説明されているようにクラスターログ転送を使用します。
ログを外部に転送する場合、ログサブシステムは Fluentd 設定マップを作成または変更して、目的のプロトコルを使用してログを送信します。外部ログアグリゲーターでプロトコルを設定する必要があります。
同じクラスターで設定マップのメソッドおよびクラスターログフォワーダーを使用することはできません。
3.2.8.1. ログのサードパーティーシステムへの転送
OpenShift Container Platform クラスターの内外の特定のエンドポイントにログを送信するには、 ClusterLogForwarder カスタムリソース (CR) で出力とパイプラインの組み合わせを指定します。入力 を使用して、特定のプロジェクトに関連付けられたアプリケーションログをエンドポイントに転送することもできます。認証は Kubernetesシークレットオブジェクトによって提供されます。
- output
定義するログデータの宛先、またはログの送信先です。出力は以下のいずれかのタイプになります。
-
elasticsearch。外部 Elasticsearch インスタンス。elasticsearch出力では、TLS 接続を使用できます。 -
fluentdForward。Fluentd をサポートする外部ログ集計ソリューション。このオプションは Fluentd forward プロトコルを使用します。fluentForward出力は TCP または TLS 接続を使用でき、シークレットに shared_key フィールドを指定して共有キーの認証をサポートします。共有キーの認証は、TLS の有無に関係なく使用できます。 -
syslog。syslog RFC3164 または RFC5424 プロトコルをサポートする外部ログ集計ソリューション。syslog出力は、UDP、TCP、または TLS 接続を使用できます。 -
cloudwatch.Amazon Web Services (AWS) がホストするモニタリングおよびログストレージサービスである Amazon CloudWatch。 -
loki。Loki: 水平方向にスケーラブルで可用性の高いマルチテナントログ集計システム。 -
kafka。Kafka ブローカー。kafka出力は TCP または TLS 接続を使用できます。 -
default。内部 OpenShift Container Platform Elasticsearch インスタンス。デフォルトの出力を設定する必要はありません。default出力を設定する場合、default出力は Red Hat OpenShift Logging Operator 用に予約されるため、エラーメッセージが送信されます。
-
- パイプライン
1 つのログタイプから 1 つまたは複数の出力への単純なルーティング、または送信するログを定義します。ログタイプは以下のいずれかになります。
-
application。クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。 -
infrastructure。openshift*、kube*、またはdefaultプロジェクトで実行される Pod のコンテナーログおよびノードファイルシステムから取得されるジャーナルログ。 -
auditノード監査システム、auditd、Kubernetes API サーバー、OpenShift API サーバー、および OVN ネットワークで生成される監査ログ。
パイプラインで
key:valueペアを使用すると、アウトバウンドログメッセージにラベルを追加できます。たとえば、他のデータセンターに転送されるメッセージにラベルを追加したり、タイプ別にログにラベルを付けたりできます。オブジェクトに追加されるラベルもログメッセージと共に転送されます。-
- input
特定のプロジェクトに関連付けられるアプリケーションログをパイプラインに転送します。
パイプラインでは、
inputRefパラメーターを使用して転送するログタイプと、outputRefパラメーターを使用してログを転送する場所を定義します。- Secret
-
ユーザー資格情報などの機密データを含む
Key:Value マップ。
次の点に注意してください。
-
ClusterLogForwarderCR オブジェクトが存在する場合に、default出力のあるパイプラインがない限り、ログはデフォルト Elasticsearch インスタンスに転送されません。 -
デフォルトで、ロギングシステムは
ClusterLoggingカスタムリソースに定義されるデフォルトの内部 Elasticsearch ログストアにコンテナーおよびインフラストラクチャーログを送信します。ただし、監査ログは内部ストアに送信しません。セキュアなストレージを提供しないためです。このデフォルト設定が要件を満たす場合は、ログ転送 API を設定する必要はありません。 -
ログタイプのパイプラインを定義しない場合、未定義タイプのログはドロップされます。たとえば、
applicationおよびauditタイプのパイプラインを指定するものの、infrastructureタイプのパイプラインを指定しないと、infrastructureログはドロップされます。 -
ClusterLogForwarderカスタムリソース (CR) で出力の複数のタイプを使用し、ログを複数の異なるプロトコルをサポートするサーバーに送信できます。 - 内部 OpenShift Container Platform Elasticsearch インスタンスは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に準拠しており、適切にセキュリティーが保護されていることを確認することが推奨されています。ロギングサブシステムはこれらの規制に準拠していません。
以下の例では、監査ログをセキュアな外部 Elasticsearch インスタンスに転送し、インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに、アプリケーションログを Kafka ブローカーに転送し、アプリケーションログを my-apps-logs プロジェクトから内部 Elasticsearch インスタンスに転送します。
ログ転送の出力とパイプラインのサンプル
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: elasticsearch-secure 3 type: "elasticsearch" url: https://elasticsearch.secure.com:9200 secret: name: elasticsearch - name: elasticsearch-insecure 4 type: "elasticsearch" url: http://elasticsearch.insecure.com:9200 - name: kafka-app 5 type: "kafka" url: tls://kafka.secure.com:9093/app-topic inputs: 6 - name: my-app-logs application: namespaces: - my-project pipelines: - name: audit-logs 7 inputRefs: - audit outputRefs: - elasticsearch-secure - default parse: json 8 labels: secure: "true" 9 datacenter: "east" - name: infrastructure-logs 10 inputRefs: - infrastructure outputRefs: - elasticsearch-insecure labels: datacenter: "west" - name: my-app 11 inputRefs: - my-app-logs outputRefs: - default - inputRefs: 12 - application outputRefs: - kafka-app labels: datacenter: "south"
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- シークレットとセキュアな URL を使用したセキュアな Elasticsearch 出力の設定。
- 出力を記述する名前。
-
出力のタイプ:
elasticsearch。 - 接頭辞を含む、有効な絶対 URL としての Elasticsearch インスタンスのセキュアな URL およびポート。
-
TLS 通信のエンドポイントで必要なシークレット。シークレットは
openshift-loggingプロジェクトに存在する必要があります。
- 4
- 非セキュアな Elasticsearch 出力の設定:
- 出力を記述する名前。
-
出力のタイプ:
elasticsearch。 - 接頭辞を含む、有効な絶対 URL として Elasticsearch インスタンスのセキュアではない URL およびポート。
- 5
- セキュアな URL を介したクライアント認証 TLS 通信を使用した Kafka 出力の設定
- 出力を記述する名前。
-
出力のタイプ:
kafka。 - Kafka ブローカーの URL およびポートを、接頭辞を含む有効な絶対 URL として指定します。
- 6
my-projectnamespace からアプリケーションログをフィルターするための入力の設定。- 7
- 監査ログをセキュアな外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
- パイプラインを説明する名前。
-
inputRefsはログタイプです (例:audit)。 -
outputRefsは使用する出力の名前です。この例では、elasticsearch-secureはセキュアな Elasticsearch インスタンスに転送され、defaultは内部 Elasticsearch インスタンスに転送されます。 - オプション: ログに追加する複数のラベル。
- 8
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 9
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
- 10
- インフラストラクチャーログをセキュアでない外部 Elasticsearch インスタンスに送信するためのパイプラインの設定。
- 11
my-projectプロジェクトから内部 Elasticsearch インスタンスにログを送信するためのパイプラインの設定。- パイプラインを説明する名前。
-
inputRefsは特定の入力my-app-logsです。 -
outputRefsはdefaultです。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 12
- パイプライン名がない場合にログを Kafka ブローカーに送信するためのパイプラインの設定。
-
inputRefsはログタイプです (例:application)。 -
outputRefsは使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
-
外部ログアグリゲーターが利用できない場合の Fluentd のログの処理
外部ロギングアグリゲーターが利用できず、ログを受信できない場合、Fluentd は継続してログを収集し、それらをバッファーに保存します。ログアグリゲーターが利用可能になると、バッファーされたログを含む、ログの転送が再開されます。バッファーが完全に一杯になると、Fluentd はログの収集を停止します。OpenShift Container Platform はログをローテーションし、それらを削除します。バッファーサイズを調整したり、永続ボリューム要求 (PVC) を Fluentd デーモンセットまたは Pod に追加したりすることはできません。
サポート対象の認証キー
ここでは、一般的なキータイプを示します。出力タイプは追加の特殊キーをサポートするものもあります。出力固有の設定フィールにまとめられています。すべての秘密鍵はオプションです。関連するキーを設定して、必要なセキュリティー機能を有効にします。キーやシークレット、サービスアカウント、ポートのオープン、またはグローバルプロキシー設定など、外部の宛先で必要となる可能性のある追加設定を作成し、維持する必要があります。OpenShift Logging は、認証の組み合わせ間の不一致を検証しません。
- Transport Layer Security (TLS)
シークレットなしで TLSURL( 'http://…'または 'ssl://…') を使用すると、基本的な TLS サーバー側認証が有効になります。シークレットを含め、次のオプションフィールドを設定して、追加の TLS 機能を有効にします。
-
tls.crt:(文字列) クライアント証明書を含むファイル名。相互認証を有効にします。tls.keyが必要です。 -
tls.key:(文字列) クライアント証明書のロックを解除するための秘密鍵を含むファイル名。tls.crtが必要です。 -
passphrase:(文字列) エンコードされた TLS 秘密鍵をデコードするためのパスフレーズ。tls.keyが必要です。 -
ca-bundle.crt:(文字列) サーバー認証用のカスタマー CA のファイル名。
-
- ユーザー名およびパスワード
-
username:(文字列) 認証ユーザー名。パスワードが必要です。 -
password:(文字列) 認証パスワード。ユーザー名が必要です。
-
- Simple Authentication Security Layer (SASL)
-
sasl.enable(boolean)SASL を明示的に有効または無効にします。ない場合は、SASL は、他のsasl.キーが設定されている場合に自動的に有効になります。 -
sasl.mechanisms:(配列) 許可された SASL メカニズム名のリスト。欠落しているか空の場合は、システムのデフォルトが使用されます。 -
sasl.allow-insecure:(ブール値) クリアテキストのパスワードを送信するメカニズムを許可します。デフォルトは false です。
-
3.2.8.1.1. シークレットの作成
次のコマンドを使用して、証明書とキーファイルを含むディレクトリーにシークレットを作成できます。
$ oc create secret generic -n openshift-logging <my-secret> \ --from-file=tls.key=<your_key_file> --from-file=tls.crt=<your_crt_file> --from-file=ca-bundle.crt=<your_bundle_file> --from-literal=username=<your_username> --from-literal=password=<your_password>
最適な結果を得るには一般的または不透明なシークレットを使用することを推奨します。
3.2.8.2. 同じ Pod 内のコンテナーから別のインデックスへの JSON ログの転送
構造化ログを、同じ Pod 内の異なるコンテナーから別のインデックスに転送できます。この機能を使用するには、複数コンテナーのサポートを使用してパイプラインを設定し、Pod にアノテーションを付ける必要があります。ログは接頭辞が app- のインデックスに書き込まれます。これに対応するために、エイリアスを使用して Elasticsearch を設定することをお勧めします。
ログの JSON 形式は、アプリケーションによって異なります。作成するインデックスが多すぎるとパフォーマンスに影響するため、この機能の使用は、互換性のない JSON 形式のログのインデックスの作成に限定してください。クエリーを使用して、さまざまな namespace または互換性のある JSON 形式のアプリケーションからログを分離します。
前提条件
- Red Hat OpenShift のロギングサブシステム: 5.5
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputDefaults: elasticsearch: enableStructuredContainerLogs: true 1 pipelines: - inputRefs: - application name: application-logs outputRefs: - default parse: json- 1
- マルチコンテナー出力を有効にします。
PodCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: v1 kind: Pod metadata: annotations: containerType.logging.openshift.io/heavy: heavy 1 containerType.logging.openshift.io/low: low spec: containers: - name: heavy 2 image: heavyimage - name: low image: lowimage
この設定により、クラスター上のシャードの数が大幅に増加する可能性があります。
3.2.8.3. OpenShift Logging 5.1 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging 5.1 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| elasticsearch | elasticsearch | Elasticsearch 6.8.1 Elasticsearch 6.8.4 Elasticsearch 7.12.2 |
| fluentdForward | fluentd forward v1 | fluentd 1.7.4 logstash 7.10.1 |
| kafka | kafka 0.11 | kafka 2.4.1 kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
以前のバージョンでは、syslog 出力は RFC-3164 でのみサポートされました。現在の syslog 出力では RFC-5424 のサポートを追加します。
3.2.8.4. OpenShift Logging 5.2 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging バージョン 5.2 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| Amazon CloudWatch | REST over HTTPS | Amazon CloudWatch の現行バージョン |
| elasticsearch | elasticsearch | Elasticsearch 6.8.1 Elasticsearch 6.8.4 Elasticsearch 7.12.2 |
| fluentdForward | fluentd forward v1 | fluentd 1.7.4 logstash 7.10.1 |
| Loki | REST over HTTP and HTTPS | OCP および Grafana ラボにデプロイされた loki 2.3.0 |
| kafka | kafka 0.11 | kafka 2.4.1 kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
3.2.8.5. OpenShift Logging 5.3 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging 5.3 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| Amazon CloudWatch | REST over HTTPS | Amazon CloudWatch の現行バージョン |
| elasticsearch | elasticsearch | Elasticsearch 7.10.1 |
| fluentdForward | fluentd forward v1 | fluentd 1.7.4 logstash 7.10.1 |
| Loki | REST over HTTP and HTTPS | OCP にデプロイされた Loki 2.2.1 |
| kafka | kafka 0.11 | kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
3.2.8.6. OpenShift Logging 5.4 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging 5.4 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| Amazon CloudWatch | REST over HTTPS | Amazon CloudWatch の現行バージョン |
| elasticsearch | elasticsearch | Elasticsearch 7.10.1 |
| fluentdForward | fluentd forward v1 | fluentd 1.14.5 logstash 7.10.1 |
| Loki | REST over HTTP and HTTPS | OCP にデプロイされた Loki 2.2.1 |
| kafka | kafka 0.11 | kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
3.2.8.7. OpenShift Logging 5.5 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging 5.5 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| Amazon CloudWatch | REST over HTTPS | Amazon CloudWatch の現行バージョン |
| elasticsearch | elasticsearch | Elasticsearch 7.10.1 |
| fluentdForward | fluentd forward v1 | fluentd 1.14.6 logstash 7.10.1 |
| Loki | REST over HTTP and HTTPS | OCP にデプロイされた Loki 2.5.0 |
| kafka | kafka 0.11 | kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
3.2.8.8. OpenShift Logging 5.6 でサポートされるログデータ出力タイプ
Red Hat OpenShift Logging 5.6 は、ログデータをターゲットログコレクターに送信するために以下の出力タイプおよびプロトコルを提供します。
Red Hat は、以下の表に記載されているそれぞれの組み合わせをテストします。ただし、これらのプロトコルを取り込むより広範囲のターゲットログコレクターにログデータを送信できるはずです。
| 出力のタイプ | プロトコル | テストで使用 |
|---|---|---|
| Amazon CloudWatch | REST over HTTPS | Amazon CloudWatch の現行バージョン |
| elasticsearch | elasticsearch | Elasticsearch 6.8.23 Elasticsearch 7.10.1 Elasticsearch 8.6.1 |
| fluentdForward | fluentd forward v1 | fluentd 1.14.6 logstash 7.10.1 |
| Loki | REST over HTTP and HTTPS | OCP にデプロイされた Loki 2.5.0 |
| kafka | kafka 0.11 | kafka 2.7.0 |
| syslog | RFC-3164、RFC-5424 | rsyslog-8.39.0 |
Fluentd は、5.6.2 の時点で Elasticsearch 8 をサポートしていません。Vector は、5.7.0 より前の fluentd/logstash/rsyslog をサポートしていません。
3.2.8.9. 外部 Elasticsearch インスタンスへのログの送信
オプションで、内部 OpenShift Container Platform Elasticsearch インスタンスに加えて、またはその代わりに外部 Elasticsearch インスタンスにログを転送できます。外部ログアグリゲーターを OpenShift Container Platform からログデータを受信するように設定する必要があります。
外部 Elasticsearch インスタンスへのログ転送を設定するには、そのインスタンスへの出力および出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。外部 Elasticsearch 出力では、HTTP(セキュアでない) または HTTPS(セキュアな HTTP) 接続を使用できます。
外部 Elasticsearch インスタンスと内部 Elasticsearch インスタンスの両方にログを転送するには、出力および外部インスタンスへのパイプライン、および default 出力を使用してログを内部インスタンスに転送するパイプラインを作成します。default 出力を作成する必要はありません。default 出力を設定する場合、default 出力は Red Hat OpenShift Logging Operator 用に予約されるため、エラーメッセージが送信されます。
ログを内部 OpenShift Container Platform Elasticsearch インスタンス のみ に転送する必要がある場合は、ClusterLogForwarder CR を作成する必要はありません。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: elasticsearch-insecure 3 type: "elasticsearch" 4 url: http://elasticsearch.insecure.com:9200 5 - name: elasticsearch-secure type: "elasticsearch" url: https://elasticsearch.secure.com:9200 6 secret: name: es-secret 7 pipelines: - name: application-logs 8 inputRefs: 9 - application - audit outputRefs: - elasticsearch-secure 10 - default 11 parse: json 12 labels: myLabel: "myValue" 13 - name: infrastructure-audit-logs 14 inputRefs: - infrastructure outputRefs: - elasticsearch-insecure labels: logs: "audit-infra"
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
elasticsearchタイプを指定します。- 5
- 外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。
http(セキュアでない) プロトコルまたはhttps(セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 6
- セキュアな接続では、
シークレットを指定して、認証するhttpsまたはhttpURL を指定できます。 - 7
https接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットはopenshift-loggingプロジェクトに存在し、tls.crt、tls.key および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。それ以外の場合、httpおよびhttps接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。詳細は、Example: Setting secret that contains a username and password.を参照してください。- 8
- オプション: パイプラインの名前を指定します。
- 9
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 11
- オプション: ログを内部 Elasticsearch インスタンスに送信するために
default出力を指定します。 - 12
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 13
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 14
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefsは、そのパイプラインを使用して転送するログタイプです (application、infrastructure、またはaudit)。 -
outputRefsは使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
例: ユーザー名とパスワードを含むシークレットの設定
ユーザー名とパスワードを含むシークレットを使用して、外部 Elasticsearch インスタンスへのセキュアな接続を認証できます。
たとえば、サードパーティーが Elasticsearch インスタンスを操作するため、相互 TLS (mTLS) キーを使用できない場合に、HTTP または HTTPS を使用してユーザー名とパスワードを含むシークレットを設定できます。
以下の例のような
SecretYAML ファイルを作成します。usernameおよびpasswordフィールドに base64 でエンコードされた値を使用します。シークレットタイプはデフォルトで不透明です。apiVersion: v1 kind: Secret metadata: name: openshift-test-secret data: username: <username> password: <password>
シークレットを作成します。
$ oc create secret -n openshift-logging openshift-test-secret.yaml
ClusterLogForwarderCR にシークレットの名前を指定します。kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: elasticsearch type: "elasticsearch" url: https://elasticsearch.secure.com:9200 secret: name: openshift-test-secret注記urlフィールドの値では、接頭辞はhttpまたはhttpsになります。CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
3.2.8.10. Fluentd 転送プロトコルを使用したログの転送
Fluentd forward プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。
forward プロトコルを使用してログ転送を設定するには、Fluentd サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder カスタムリース (CR) を作成します。Fluentd の出力は TCP(セキュアでない) または TLS(セキュアな TCP) 接続を使用できます。
または、設定マップを使用して 転送 プロトコルを使用してログを転送することもできます。ただし、この方法は OpenShift Container Platform では非推奨となり、今後のリリースで取り除かれます。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: fluentd-server-secure 3 type: fluentdForward 4 url: 'tls://fluentdserver.security.example.com:24224' 5 secret: 6 name: fluentd-secret - name: fluentd-server-insecure type: fluentdForward url: 'tcp://fluentdserver.home.example.com:24224' pipelines: - name: forward-to-fluentd-secure 7 inputRefs: 8 - application - audit outputRefs: - fluentd-server-secure 9 - default 10 parse: json 11 labels: clusterId: "C1234" 12 - name: forward-to-fluentd-insecure 13 inputRefs: - infrastructure outputRefs: - fluentd-server-insecure labels: clusterId: "C1234"
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
fluentdForwardタイプを指定します。- 5
- 外部 Fluentd インスタンスの URL およびポートを有効な絶対 URL として指定します。
tcp(セキュアでない) プロトコルまたはtls(セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 6
tls接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-loggingプロジェクトに存在し、tls.crt、tls.key および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。それ以外の場合は、http および https 接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。詳細は、Example: Setting secret that contains a username and password.を参照してください。- 7
- オプション: パイプラインの名前を指定します。
- 8
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 9
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 10
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default出力を指定します。 - 11
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 13
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefsは、そのパイプラインを使用して転送するログタイプです (application、infrastructure、またはaudit)。 -
outputRefsは使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
3.2.8.10.1. Logstash が fluentd からデータを取り込むためのナノ秒精度の有効化
Logstash が fluentd からログデータを取り込むには、Logstash 設定ファイルでナノ秒精度を有効にする必要があります。
手順
-
Logstash 設定ファイルで、
nanosecond_precisionをtrueに設定します。
Logstash 設定ファイルの例
input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }
3.2.8.11. syslog プロトコルを使用したログの転送
syslog RFC3164 または RFC5424 プロトコルを使用して、デフォルトの Elasticsearch ログストアの代わり、またはこれに加えてプロトコルを受け入れるように設定された外部ログアグリゲーターにログのコピーを送信できます。syslog サーバーなど、外部ログアグリゲーターを OpenShift Container Platform からログを受信するように設定する必要があります。
syslog プロトコルを使用してログ転送を設定するには、syslog サーバーに対する 1 つ以上の出力およびそれらの出力を使用するパイプラインと共に ClusterLogForwarder カスタムリース (CR) を作成します。syslog 出力では、UDP、TCP、または TLS 接続を使用できます。
または、設定マップを使用して syslog RFC3164 プロトコルを使用してログを転送することもできます。ただし、この方法は OpenShift Container Platform では非推奨となり、今後のリリースで取り除かれます。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: rsyslog-east 3 type: syslog 4 syslog: 5 facility: local0 rfc: RFC3164 payloadKey: message severity: informational url: 'tls://rsyslogserver.east.example.com:514' 6 secret: 7 name: syslog-secret - name: rsyslog-west type: syslog syslog: appName: myapp facility: user msgID: mymsg procID: myproc rfc: RFC5424 severity: debug url: 'udp://rsyslogserver.west.example.com:514' pipelines: - name: syslog-east 8 inputRefs: 9 - audit - application outputRefs: 10 - rsyslog-east - default 11 parse: json 12 labels: secure: "true" 13 syslog: "east" - name: syslog-west 14 inputRefs: - infrastructure outputRefs: - rsyslog-west - default labels: syslog: "west"
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
syslogタイプを指定します。- 5
- オプション: 以下に一覧表示されている syslog パラメーターを指定します。
- 6
- 外部 syslog インスタンスの URL およびポートを指定します。
udp(セキュアでない)、tcp(セキュアでない) プロトコル、またはtls(セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。 - 7
tls接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-loggingプロジェクトに存在し、tls.crt、tls.key および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。- 8
- オプション: パイプラインの名前を指定します。
- 9
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 10
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
- 11
- オプション: ログを内部 Elasticsearch インスタンスに転送するために
default出力を指定します。 - 12
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 13
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。
- 14
- オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。
- パイプラインを説明する名前。
-
inputRefsは、そのパイプラインを使用して転送するログタイプです (application、infrastructure、またはaudit)。 -
outputRefsは使用する出力の名前です。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
3.2.8.11.1. メッセージ出力へのログソース情報の追加
AddLogSource フィールドを ClusterLogForwarder カスタムリソース (CR) に追加することで、namespace_name、pod_name、および container_name 要素をレコードの メッセージ フィールドに追加できます。
spec:
outputs:
- name: syslogout
syslog:
addLogSource: true
facility: user
payloadKey: message
rfc: RFC3164
severity: debug
tag: mytag
type: syslog
url: tls://syslog-receiver.openshift-logging.svc:24224
pipelines:
- inputRefs:
- application
name: test-app
outputRefs:
- syslogoutこの設定は、RFC3164 と RFC5424 の両方と互換性があります。
AddLogSource を使用しない場合の syslog メッセージ出力の例
<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - - {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}
AddLogSource を使用した syslog メッセージ出力の例
<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - - namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}
3.2.8.11.2. syslog パラメーター
syslog 出力には、以下を設定できます。詳細は、syslog の RFC3164 または RFC5424 RFC を参照してください。
facility: syslog ファシリティー。値には 10 進数の整数または大文字と小文字を区別しないキーワードを使用できます。
-
カーネルメッセージの場合は、
0またはkern -
ユーザーレベルのメッセージの場合は、
1またはuser。デフォルトです。 -
メールシステムの場合は、
2またはmail -
システムデーモンの場合は、
3またはdaemon -
セキュリティー/認証メッセージの場合は、
4またはauth -
syslogd によって内部に生成されるメッセージの場合は、
5またはsyslog -
ラインプリンターサブシステムの場合は、
6またはlpr -
ネットワーク news サブシステムの場合は、
7またはnews -
UUCP サブシステムの場合は、
8またはuucp -
クロックデーモンの場合は、
9またはcron -
セキュリティー認証メッセージの場合は、
10またはauthpriv -
FTP デーモンの場合は、
11またはftp -
NTP サブシステムの場合は、
12またはntp -
syslog 監査ログの場合は、
13またはsecurity -
syslog アラートログの場合は、
14またはconsole -
スケジューリングデーモンの場合は、
15またはsolaris-cron -
ローカルに使用される facility の場合は、
16–23またはlocal0–local7
-
カーネルメッセージの場合は、
オプション:
payloadKey: syslog メッセージのペイロードとして使用するレコードフィールド。注記payloadKeyパラメーターを設定すると、他のパラメーターが syslog に転送されなくなります。- rfc: syslog を使用してログを送信するために使用される RFC。デフォルトは RFC5424 です。
severity: 送信 syslog レコードに設定される syslog の重大度。値には 10 進数の整数または大文字と小文字を区別しないキーワードを使用できます。
-
システムが使用不可であることを示すメッセージの場合は、
0またはEmergency -
即時にアクションを実行する必要があることを示すメッセージの場合は、
1またはAlert -
重大な状態を示すメッセージの場合は、
2またはCritical -
エラーの状態を示すメッセージの場合は、
3またはError -
警告状態を示すメッセージの場合は、
4またはWarning -
正常であるが重要な状態を示すメッセージの場合は、
5またはNotice -
情報を提供するメッセージの場合は、
6またはInformational -
デバッグレベルのメッセージを示唆するメッセージの場合は、
7またはDebug。デフォルトです。
-
システムが使用不可であることを示すメッセージの場合は、
- tag: タグは、syslog メッセージでタグとして使用するレコードフィールドを指定します。
- trimPrefix: 指定された接頭辞をタグから削除します。
3.2.8.11.3. 追加の RFC5424 syslog パラメーター
以下のパラメーターは RFC5424 に適用されます。
-
appName: APP-NAME は、ログを送信したアプリケーションを識別するフリーテキストの文字列です。
RFC5424に対して指定する必要があります。 -
msgID: MSGID は、メッセージのタイプを識別するフリーテキスト文字列です。
RFC5424に対して指定する必要があります。 -
procID: PROCID はフリーテキスト文字列です。値が変更される場合は、syslog レポートが中断していることを示します。
RFC5424に対して指定する必要があります。
3.2.8.12. ログの Amazon CloudWatch への転送
Amazon Web Services (AWS) がホストするモニタリングおよびログストレージサービスである Amazon CloudWatch にログを転送できます。デフォルトのログストアに加えて、またはログストアの代わりに、CloudWatch にログを転送できます。
CloudWatch へのログ転送を設定するには、CloudWatch の出力および出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。
手順
aws_access_key_idおよびaws_secret_access_keyフィールドを使用するSecretYAML ファイルを作成し、base64 でエンコードされた AWS 認証情報を指定します。以下に例を示します。apiVersion: v1 kind: Secret metadata: name: cw-secret namespace: openshift-logging data: aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
シークレットを作成します。以下に例を示します。
$ oc apply -f cw-secret.yaml
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。このファイルに、シークレットの名前を指定します。以下に例を示します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: cw-secret 8 pipelines: - name: infra-logs 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
cloudwatchタイプを指定します。- 5
- オプション: ログをグループ化する方法を指定します。
-
logTypeは、ログタイプごとにロググループを作成します。 -
namespaceNameは、アプリケーションの namespace ごとにロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。 -
namespaceUUIDは、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
-
- 6
- オプション: ロググループの名前に含まれるデフォルトの
infrastructureName接頭辞を置き換える文字列を指定します。 - 7
- AWS リージョンを指定します。
- 8
- AWS 認証情報が含まれるシークレットの名前を指定します。
- 9
- オプション: パイプラインの名前を指定します。
- 10
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
例: Amazon CloudWatch での ClusterLogForwarder の使用
ここでは、ClusterLogForwarder カスタムリソース (CR) のサンプルと、Amazon CloudWatch に出力するログデータが表示されます。
mycluster という名前の OpenShift Container Platform クラスターを実行しているとします。以下のコマンドは、クラスターの infrastructureName を返します。これは、後で aws コマンドの作成に使用します。
$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName "mycluster-7977k"
この例のログデータを生成するには、app という名前の namespace で busybox pod を実行します。busybox pod は、3 秒ごとに stdout にメッセージを書き込みます。
$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done' $ oc logs -f busybox My life is my message My life is my message My life is my message ...
busybox pod が実行される app namespace の UUID を検索できます。
$ oc get ns/app -ojson | jq .metadata.uid "794e1e1a-b9f5-4958-a190-e76a9b53d7bf"
ClusterLogForwarder カスタムリソース (CR) で、インフラストラクチャー、監査、および アプリケーションログ タイプを all-logs パイプラインへの入力として設定します。また、このパイプラインを cw 出力に接続し、us-east-2 リージョンの CloudWatch インスタンスに転送します。
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
outputs:
- name: cw
type: cloudwatch
cloudwatch:
groupBy: logType
region: us-east-2
secret:
name: cw-secret
pipelines:
- name: all-logs
inputRefs:
- infrastructure
- audit
- application
outputRefs:
- cwCloudWatch の各リージョンには、3 つのレベルのオブジェクトが含まれます。
ロググループ
ログストリーム
- ログイベント
ClusterLogForwarding CR の groupBy: logType の場合に、inputRefs にある 3 つのログタイプで Amazon Cloudwatch に 3 つのロググループを生成します。
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.application" "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
各ロググループにはログストリームが含まれます。
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName "kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName "ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log" "ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log" "ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log" ...
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log" "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log" "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log" ...
各ログストリームにはログイベントが含まれます。busybox Pod からログイベントを表示するには、application ロググループからログストリームを指定します。
$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
{
"events": [
{
"timestamp": 1629422704178,
"message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
"ingestionTime": 1629422744016
},
...例: ロググループ名の接頭辞のカスタマイズ
ロググループ名では、デフォルトの infrastructureName 接頭辞 mycluster-7977k は demo-group-prefix のように任意の文字列に置き換えることができます。この変更を加えるには、ClusterLogForwarding CR の groupPrefix フィールドを更新します。
cloudwatch:
groupBy: logType
groupPrefix: demo-group-prefix
region: us-east-2
groupPrefix の値は、デフォルトの infrastructureName 接頭辞を置き換えます。
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "demo-group-prefix.application" "demo-group-prefix.audit" "demo-group-prefix.infrastructure"
例: アプリケーションの namespace 名をもとにロググループの命名
クラスター内のアプリケーション namespace ごとに、名前がアプリケーション namespace 名をもとにする CloudWatch にロググループを作成できます。
アプリケーションの namespace オブジェクトを削除して、同じ名前の新しいオブジェクトを作成する場合は、CloudWatch は以前と同じロググループを使用し続けます。
相互に名前が同じアプリケーション namespace オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外で、生成されるログメッセージを相互に区別する必要がある場合は、代わりに Naming log groups for application namespace UUIDs のセクションを参照してください。
アプリケーション namespace 名を基にした名前を指定してアプリケーションロググループを作成するには、ClusterLogForwarder CR で groupBy フィールドの値を namespaceName に設定します。
cloudwatch:
groupBy: namespaceName
region: us-east-2
groupBy を namespaceName に設定すると、アプリケーションロググループのみが影響を受けます。これは、audit および infrastructure のロググループには影響しません。
Amazon Cloudwatch では、namespace 名が各ロググループ名の最後に表示されます。アプリケーション namespace (app) が 1 つであるため、以下の出力は mycluster-7977k.application ではなく、新しい mycluster-7977k.app ロググループを示しています。
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.app" "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
この例のクラスターに複数のアプリケーション namespace が含まれる場合は、出力には namespace ごとに複数のロググループが表示されます。
groupBy フィールドは、アプリケーションロググループだけに影響します。これは、audit および infrastructure のロググループには影響しません。
例: アプリケーション namespace UUID をもとにロググループの命名
クラスター内のアプリケーション namespace ごとに、名前がアプリケーション namespace の UUID をもとにする CloudWatch にロググループを作成できます。
アプリケーションの namespace オブジェクトを削除して新規のロググループを作成する場合は、CloudWatch で新しいロググループを作成します。
相互に名前が異なるアプリケーション namespace オブジェクトを引き継ぐ予定の場合は、この例で説明されている方法を使用します。それ以外の場合は、前述の例: Naming log groups for application namespace name のセクションを参照してください。
アプリケーション namespace UUID をもとにログエントリーに名前を付けるには、ClusterLogForwarder CR で groupBy フィールドの値を namespaceUUID に設定します。
cloudwatch:
groupBy: namespaceUUID
region: us-east-2
Amazon Cloudwatch では、namespace UUID が各ロググループ名の最後に表示されます。アプリケーション namespace (app) が 1 つであるため、以下の出力は mycluster-7977k.application ではなく、新しい mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf ロググループを示しています。
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
groupBy フィールドは、アプリケーションロググループだけに影響します。これは、audit および infrastructure のロググループには影響しません。
3.2.8.12.1. STS 対応クラスターから Amazon CloudWatch へのログ転送
AWS Security Token Service (STS) が有効になっているクラスターの場合に、AWS サービスアカウントを手動で作成するか、Cloud Credential Operator (CCO) ユーティリティー ccoctl を使用してクレデンシャルのリクエストを作成できます。
この機能は、vector コレクターではサポートされていません。
AWS 認証情報リクエストの作成
以下のテンプレートを使用して、
CredentialsRequestカスタムリソース YAML を作成します。CloudWatch クレデンシャルリクエストのテンプレート
apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <your_role_name>-credrequest namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - action: - logs:PutLogEvents - logs:CreateLogGroup - logs:PutRetentionPolicy - logs:CreateLogStream - logs:DescribeLogGroups - logs:DescribeLogStreams effect: Allow resource: arn:aws:logs:*:*:* secretRef: name: <your_role_name> namespace: openshift-logging serviceAccountNames: - logcollectorccoctlコマンドを使用して、CredentialsRequestCR を使用して AWS のロールを作成します。CredentialsRequestオブジェクトでは、このccoctlコマンドを使用すると、特定の OIDC アイデンティティープロバイダーに紐付けされたトラストポリシーと、CloudWatch リソースでの操作実行パーミッションを付与するパーミッションポリシーを指定して IAM ロールを作成します。このコマンドは、/<path_to_ccoctl_output_dir>/manifests/openshift-logging-<your_role_name>-credentials.yamlに YAML 設定ファイルも作成します。このシークレットファイルには、AWS IAM ID プロバイダーでの認証中に使用されるrole_arnキー/値が含まれています。ccoctl aws create-iam-roles \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \ --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com 1- 1
- <name> は、クラウドリソースのタグ付けに使用される名前であり、STS クラスターのインストール中に使用される名前と一致する必要があります。
作成したシークレットを適用します。
oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml
ClusterLogForwarderカスタムリソースを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: <your_role_name> 8 pipelines: - name: to-cloudwatch 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
cloudwatchタイプを指定します。- 5
- オプション: ログをグループ化する方法を指定します。
-
logTypeは、ログタイプごとにロググループを作成します。 -
namespaceNameは、アプリケーションの namespace ごとにロググループを作成します。インフラストラクチャーおよび監査ログは影響を受けず、logTypeによってグループ化されたままになります。 -
namespaceUUIDは、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
-
- 6
- オプション: ロググループの名前に含まれるデフォルトの
infrastructureName接頭辞を置き換える文字列を指定します。 - 7
- AWS リージョンを指定します。
- 8
- AWS 認証情報が含まれるシークレットの名前を指定します。
- 9
- オプション: パイプラインの名前を指定します。
- 10
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 11
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
関連情報
3.2.8.12.1.1. 既存の AWS ロールを使用した AWS CloudWatch のシークレット作成
AWS の既存のロールがある場合は、oc create secret --from-literal コマンドを使用して、STS で AWS のシークレットを作成できます。
oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions
シークレットの例
apiVersion: v1 kind: Secret metadata: namespace: openshift-logging name: my-secret-name stringData: role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions
3.2.8.13. ログの Loki への転送
内部のデフォルト OpenShift Container Platform Elasticsearch インスタンスに加えて、またはその代わりに外部の Loki ロギングシステムにログを転送できます。
Loki へのログ転送を設定するには、Loki の出力と、出力を使用するパイプラインで ClusterLogForwarder カスタムリソース (CR) を作成する必要があります。Loki への出力は HTTP (セキュアでない) または HTTPS (セキュアな HTTP) 接続を使用できます。
前提条件
-
CR の
urlフィールドで指定する URL で Loki ロギングシステムが実行されている必要がある。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: loki-insecure 3 type: "loki" 4 url: http://loki.insecure.com:3100 5 loki: tenantKey: kubernetes.namespace_name labelKeys: kubernetes.labels.foo - name: loki-secure 6 type: "loki" url: https://loki.secure.com:3100 secret: name: loki-secret 7 loki: tenantKey: kubernetes.namespace_name 8 labelKeys: kubernetes.labels.foo 9 pipelines: - name: application-logs 10 inputRefs: 11 - application - audit outputRefs: 12 - loki-secure- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
- タイプを
lokiとして指定します。 - 5
- Loki システムの URL およびポートを有効な絶対 URL として指定します。
http(セキュアでない) プロトコルまたはhttps(セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。HTTP(S) 通信用の Loki のデフォルトポートは 3100 です。 - 6
- セキュアな接続では、
シークレットを指定して、認証するhttpsまたはhttpURL を指定できます。 - 7
https接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットはopenshift-loggingプロジェクトに存在し、tls.crt、tls.key および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。それ以外の場合、httpおよびhttps接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。詳細は、Example: Setting secret that contains a username and password.を参照してください。- 8
- オプション: メタデータキーフィールドを指定して、Loki の
TenantIDフィールドの値を生成します。たとえば、tenantKey: kubernetes.namespace_nameを設定すると、Kubernetes namespace の名前を Loki のテナント ID の値として使用します。他にどのログレコードフィールドを指定できるかを確認するには、以下の Additional resources セクションの Log Record Fields リンクを参照してください。 - 9
- オプション: デフォルトの Loki ラベルを置き換えるメタデータフィールドキーの一覧を指定します。loki ラベル名は、正規表現
[a-zA-Z_:][a-zA-Z0-9_:]*と一致する必要があります。ラベル名を形成するため、メタデータキーの無効な文字は_に置き換えられます。たとえば、kubernetes.labels.foometa-data キーは Loki ラベルkubernetes_labels_fooになります。labelKeysを設定しないと、デフォルト値は[log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]です。Loki で指定可能なラベルのサイズと数に制限があるため、ラベルのセットを小さくします。Configuring Loki, limits_config を参照してください。クエリーフィルターを使用して、ログレコードフィールドに基づいてクエリーを実行できます。 - 10
- オプション: パイプラインの名前を指定します。
- 11
- パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - 12
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
注記Loki ではログストリームを正しくタイムスタンプで順序付ける必要があるため、
labelKeysには指定しなくてもkubernetes_hostラベルセットが常に含まれます。このラベルセットが含まれることで、各ストリームが 1 つのホストから発信されるので、ホストのクロック間の誤差が原因でタイムスタンプの順番が乱れないようになります。CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
3.2.8.13.1. "entry out of order" エラーのトラブルシューティング
Fluentd がレート制限を超えるサイズの大きいメッセージブロックを Loki ロギングシステムに転送する場合は、Loki は "entry out of order" のエラーを生成します。この問題を修正するには、Loki サーバー設定ファイル loki.yaml のいくつかの値を更新します。
loki.yaml は、Grafana がホストする Loki では使用できません。このトピックは、Grafana がホストする Loki サーバーには適用されません。
条件
-
Cluster Log Forwarderカスタムリソースは、ログを Loki に転送するように設定されています。 システムは、次のような 2MB を超えるメッセージのブロックを Loki に送信します。
"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\ ....... ...... ...... ...... \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}oc logs -c fluentdと入力すると、OpenShift Logging クラスターの Fluentd ログに次のメッセージが表示されます。429 Too Many Requests Ingestion rate limit exceeded (limit: 8388608 bytes/sec) while attempting to ingest '2140' lines totaling '3285284' bytes 429 Too Many Requests Ingestion rate limit exceeded' or '500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5277702 vs. 4194304)'
Loki サーバーでログを開くと、次のような
entry out of orderメッセージが表示されます。,\nentry with timestamp 2021-08-18 05:58:55.061936 +0000 UTC ignored, reason: 'entry out of order' for stream: {fluentd_thread=\"flush_thread_0\", log_type=\"audit\"},\nentry with timestamp 2021-08-18 06:01:18.290229 +0000 UTC ignored, reason: 'entry out of order' for stream: {fluentd_thread="flush_thread_0", log_type="audit"}
手順
Loki サーバーの
loki.yaml設定ファイルの次のフィールドを、ここに示す値で更新します。-
grpc_server_max_recv_msg_size: 8388608 -
chunk_target_size: 8388608 -
ingestion_rate_mb: 8 -
ingestion_burst_size_mb: 16
-
-
loki.yamlの変更を Loki サーバーに適用します。
loki.yaml ファイルの例
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
grpc_server_max_recv_msg_size: 8388608
ingester:
wal:
enabled: true
dir: /tmp/wal
lifecycler:
address: 127.0.0.1
ring:
kvstore:
store: inmemory
replication_factor: 1
final_sleep: 0s
chunk_idle_period: 1h # Any chunk not receiving new logs in this time will be flushed
chunk_target_size: 8388608
max_chunk_age: 1h # All chunks will be flushed when they hit this age, default is 1h
chunk_retain_period: 30s # Must be greater than index read cache TTL if using an index cache (Default index read cache TTL is 5m)
max_transfer_retries: 0 # Chunk transfers disabled
schema_config:
configs:
- from: 2020-10-24
store: boltdb-shipper
object_store: filesystem
schema: v11
index:
prefix: index_
period: 24h
storage_config:
boltdb_shipper:
active_index_directory: /tmp/loki/boltdb-shipper-active
cache_location: /tmp/loki/boltdb-shipper-cache
cache_ttl: 24h # Can be increased for faster performance over longer query periods, uses more disk space
shared_store: filesystem
filesystem:
directory: /tmp/loki/chunks
compactor:
working_directory: /tmp/loki/boltdb-shipper-compactor
shared_store: filesystem
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 12h
ingestion_rate_mb: 8
ingestion_burst_size_mb: 16
chunk_store_config:
max_look_back_period: 0s
table_manager:
retention_deletes_enabled: false
retention_period: 0s
ruler:
storage:
type: local
local:
directory: /tmp/loki/rules
rule_path: /tmp/loki/rules-temp
alertmanager_url: http://localhost:9093
ring:
kvstore:
store: inmemory
enable_api: true
関連情報
3.2.8.14. ログの Google Cloud Platform (GCP) への転送
内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、ログを Google Cloud Logging に転送できます。
この機能を Fluentd で使用することはサポートされていません。
前提条件
- Red Hat OpenShift Operator 5.5.1 以降のロギングサブシステム
手順
Google サービスアカウントキー を使用してシークレットを作成します。
$ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>以下のテンプレートを使用して、
ClusterLogForwarderカスタムリソース YAML を作成します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" namespace: "openshift-logging" spec: outputs: - name: gcp-1 type: googleCloudLogging secret: name: gcp-secret googleCloudLogging: projectId : "openshift-gce-devel" 1 logId : "app-gcp" 2 pipelines: - name: test-app inputRefs: 3 - application outputRefs: - gcp-1- 1
- ログを保存する GCP リソース階層 の場所に応じて、
projectId、folderId、organizationId、またはbillingAccountIdフィールドとそれに対応する値を設定します。 - 2
- Log Entry の
logNameフィールドに追加する値を設定します。 - 3
- パイプラインを使用して転送するログタイプ (
application、infrastructure、またはaudit) を指定します。
3.2.8.15. ログの Splunk への転送
内部のデフォルトの OpenShift Container Platform ログストアに加えて、またはその代わりに、Splunk HTTP Event Collector (HEC) にログを転送できます。
この機能を Fluentd で使用することはサポートされていません。
前提条件
- Red Hat OpenShift Logging Operator 5.6 以降
- コレクターとして vector が指定された ClusterLogging インスタンス
- Base64 でエンコードされた Splunk HEC トークン
手順
Base64 でエンコードされた Splunk HEC トークンを使用してシークレットを作成します。
$ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
以下のテンプレートを使用して、
ClusterLogForwarderカスタムリソース (CR) を作成または編集します。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" 1 namespace: "openshift-logging" 2 spec: outputs: - name: splunk-receiver 3 secret: name: vector-splunk-secret 4 type: splunk 5 url: <http://your.splunk.hec.url:8088> 6 pipelines: 7 - inputRefs: - application - infrastructure name: 8 outputRefs: - splunk-receiver 9- 1
- ClusterLogForwarder CR の名前は
instanceである必要があります。 - 2
- ClusterLogForwarder CR の namespace は
openshift-loggingである必要があります。 - 3
- 出力の名前を指定します。
- 4
- HEC トークンが含まれるシークレットの名前を指定します。
- 5
- 出力タイプを
splunkとして指定します。 - 6
- Splunk HEC の URL (ポートを含む) を指定します。
- 7
- パイプラインを使用して転送するログタイプ (
application、infrastructure、またはaudit) を指定します。 - 8
- オプション: パイプラインの名前を指定します。
- 9
- このパイプラインでログを転送する時に使用する出力の名前を指定します。
3.2.8.16. HTTP 経由でのログ転送
HTTP 経由でのログ転送は、fluentd および vector コレクターでサポートされています。有効にするには、ClusterLogForwarder カスタムリソース (CR) の出力タイプを http に指定します。
手順
- 以下のテンプレートを使用して、ClusterLogForwarder カスタムリソース (CR) を作成または編集します。
ClusterLogForwarder CR の例
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
outputs:
- name: httpout-app
type: http
url: 1
http:
headers: 2
h1: v1
h2: v2
method: POST
secret:
name: 3
tls:
insecureSkipVerify: 4
pipelines:
- name:
inputRefs:
- application
outputRefs:
- 5
3.2.8.17. 特定のプロジェクトからのアプリケーションログの転送
クラスターログフォワーダーを使用して、外部ログアグリゲーターに、特定のプロジェクトからアプリケーションログのコピーを送信できます。これは、デフォルトの Elasticsearch ログストアの代わりに、またはこれに加えてデフォルトの Elasticsearch ログストアを使用して実行できます。また、外部ログアグリゲーターを OpenShift Container Platform からログデータを受信できるように設定する必要もあります。
アプリケーションログのプロジェクトからの転送を設定するには、プロジェクトから少なくとも 1 つの入力で ClusterLogForwarder カスタムリソース (CR) を作成し、他のログアグリゲーターのオプション出力、およびそれらの入出力を使用するパイプラインを作成する必要があります。
前提条件
- 指定されたプロトコルまたは形式を使用してロギングデータを受信するように設定されたロギングサーバーが必要です。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: fluentd-server-secure 3 type: fluentdForward 4 url: 'tls://fluentdserver.security.example.com:24224' 5 secret: 6 name: fluentd-secret - name: fluentd-server-insecure type: fluentdForward url: 'tcp://fluentdserver.home.example.com:24224' inputs: 7 - name: my-app-logs application: namespaces: - my-project pipelines: - name: forward-to-fluentd-insecure 8 inputRefs: 9 - my-app-logs outputRefs: 10 - fluentd-server-insecure parse: json 11 labels: project: "my-project" 12 - name: forward-to-fluentd-secure 13 inputRefs: - application - audit - infrastructure outputRefs: - fluentd-server-secure - default labels: clusterId: "C1234"
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
- 出力の名前を指定します。
- 4
- 出力タイプ
elasticsearch、fluentdForward、syslog、またはkafkaを指定します。 - 5
- 外部ログアグリゲーターの URL およびポートを有効な絶対 URL として指定します。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。
- 6
tls接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットはopenshift-loggingプロジェクトに存在し、 tls.crt、 tls.key、 および ca-bundle.crt キーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。- 7
- 指定されたプロジェクトからアプリケーションログをフィルターするための入力の設定。
- 8
- 入力を使用してプロジェクトアプリケーションログを外部 Fluentd インスタンスに送信するためのパイプラインの設定。
- 9
my-app-logs入力。- 10
- 使用する出力の名前。
- 11
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 12
- オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
- 13
- ログを他のログアグリゲーターに送信するためのパイプラインの設定。
- オプション: パイプラインの名前を指定します。
-
パイプラインを使用して転送するログタイプ (
application、infrastructureまたはaudit) を指定します。 - このパイプラインでログを転送する時に使用する出力の名前を指定します。
-
オプション: ログを内部 Elasticsearch インスタンスに転送するために
default出力を指定します。 - オプション: 文字列。ログに追加する 1 つまたは複数のラベル。
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
3.2.8.18. 特定の Pod からのアプリケーションログの転送
クラスター管理者は、Kubernetes Pod ラベルを使用して特定の Pod からログデータを収集し、これをログコレクターに転送できます。
アプリケーションがさまざまな namespace の他の Pod と共に実行される Pod で設定されるとします。これらの Pod にアプリケーションを識別するラベルがある場合は、それらのログデータを収集し、特定のログコレクターに出力できます。
Pod ラベルを指定するには、1 つ以上の matchLabels のキー/値のペアを使用します。複数のキー/値のペアを指定する場合、Pod は選択されるそれらすべてに一致する必要があります。
手順
ClusterLogForwarderCR オブジェクトを定義する YAML ファイルを作成または編集します。ファイルで、以下の例が示すようにinputs[].name.application.selector.matchLabelsの下で単純な等価ベース (Equality-based) のセレクターを使用して Pod ラベルを指定します。ClusterLogForwarderCR YAML ファイルのサンプルapiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: pipelines: - inputRefs: [ myAppLogData ] 3 outputRefs: [ default ] 4 parse: json 5 inputs: 6 - name: myAppLogData application: selector: matchLabels: 7 environment: production app: nginx namespaces: 8 - app1 - app2 outputs: 9 - default ...
- 1
ClusterLogForwarderCR の名前はinstanceである必要があります。- 2
ClusterLogForwarderCR の namespace はopenshift-loggingである必要があります。- 3
inputs[].nameから 1 つ以上のコンマ区切りの値を指定します。- 4
outputs[]から 1 つ以上のコンマ区切りの値を指定します。- 5
- オプション: 構造化された JSON ログエントリーを
structuredフィールドの JSON オブジェクトとして転送するかどうかを指定します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は構造化フィールドを削除し、代わりにログエントリーをデフォルトのインデックスapp-00000xに送信します。 - 6
- Pod ラベルの一意のセットを持つ各アプリケーションの一意の
inputs[].nameを定義します。 - 7
- 収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。
- 8
- オプション: namespace を 1 つ以上指定します。
- 9
- ログデータを転送する 1 つ以上の出力を指定します。ここで表示されるオプションの
default出力はログデータを内部 Elasticsearch インスタンスに送信します。
-
オプション: ログデータの収集を特定の namespace に制限するには、前述の例のように
inputs[].name.application.namespacesを使用します。 オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。
-
Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の
inputs[].nameセクションを作成します。 -
このアプリケーションの Pod ラベルに一致するように、
selectorsを更新します。 新規の
inputs[].name値をinputRefsに追加します。以下に例を示します。- inputRefs: [ myAppLogData, myOtherAppLogData ]
-
Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
関連情報
-
Kubernetes の
matchLabelsの詳細は、セットベースの要件をサポートするリソース を参照してください。
関連情報
3.2.8.19. ログ転送のトラブルシューティング
ClusterLogForwarder カスタムリソース (CR) の作成時に、Red Hat OpenShift Logging Operator により Fluentd Pod が自動的に再デプロイされない場合は、Fluentd Pod を削除して、強制的に再デプロイできます。
前提条件
-
ClusterLogForwarderカスタムリソース (CR) オブジェクトを作成している。
手順
Fluentd Pod を削除して強制的に再デプロイします。
$ oc delete pod --selector logging-infra=collector
3.2.9. JSON ロギングの有効化
ログ転送 API を設定して、構造化されたオブジェクトに対して JSON 文字列を解析できます。
3.2.9.1. JSON ログの解析
JSON ログなどのログは、通常 message フィールド内の文字列として表されます。これにより、JSON ドキュメント内の特定のフィールドをクエリーすることが困難になります。OpenShift Logging のログ転送 API を使用すると、JSON ログを構造化オブジェクトに解析し、それらを OpenShift Logging が管理する Elasticsearch またはログ転送 API でサポートされる他のサードパーティーシステムに転送できます。
以下の構造化された JSON ログエントリーがあると想定して、これがどのように機能するか説明します。
構造化された JSON ログエントリーの例
{"level":"info","name":"fred","home":"bedrock"}
通常、ClusterLogForwarder カスタムリソース (CR) は、そのログエントリーを message フィールドに転送します。message フィールドには、以下の例のように JSON ログエントリーと同等の JSON 引用符で囲まれた文字列が含まれます。
message フィールドの例
{"message":"{\"level\":\"info\",\"name\":\"fred\",\"home\":\"bedrock\"",
"more fields..."}
JSON ログの解析を有効にするには、以下の例のように、parse: json を ClusterLogForwarder CR のパイプラインに追加します。
parse: json を示すスニペット例
pipelines: - inputRefs: [ application ] outputRefs: myFluentd parse: json
parse: json を使用して JSON ログの解析を有効にすると、以下の例のように CR は 構造化 フィールドに JSON-structured ログエントリーをコピーします。元の message フィールドは変更されません。
構造化された JSON ログエントリーを含む 構造化された 出力例
{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
"more fields..."}
ログエントリーに有効な構造化された JSON が含まれていない場合に、構造化された フィールドはなくなります。
特定のロギングプラットフォームの JSON ログの解析を有効にするには、Forwarding logs to third-party systems を参照してください。
3.2.9.2. Elasticsearch の JSON ログデータの設定
JSON ログが複数のスキーマに従う場合は、それらを 1 つのインデックスに保存すると、タイプの競合やカーディナリティーの問題が発生する可能性があります。これを回避するには、1 つの出力定義に、各スキーマをグループ化するように ClusterLogForwarder カスタムリソース (CR) を設定する必要があります。これにより、各スキーマが別のインデックスに転送されます。
JSON ログを OpenShift Logging によって管理されるデフォルトの Elasticsearch インスタンスに転送する場合に、設定に基づいて新規インデックスが生成されます。インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。
構造化タイプ
ClusterLogForwarder CR で以下の構造タイプを使用し、Elasticsearch ログストアのインデックス名を作成できます。
structuredTypeKey(string, optional) は、メッセージフィールドの名前です。このフィールドの値 (ある場合) はインデックス名の作成に使用されます。-
kubernetes.labels.<key>は、インデックス名の作成に使用される Kubernetes pod ラベルの値です。 -
openshift.labels.<key>は、インデックス名の作成に使用されるClusterLogForwarderCR のpipeline.label.<key> 要素です。 -
kubernetes.container_nameはコンテナー名を使用してインデックス名を作成します。
-
-
structuredTypeName:(文字列、オプション)structuredTypeKeyが設定されておらず、そのキーが存在しない場合、OpenShift Logging はstructuredTypeNameの値を構造化型として使用します。structuredTypeKeyandstructuredTypeNameの両方を使用する場合に、structuredTypeNameは、構造化されたTypeKeyのキーが JSON ログデータにない場合にフォールバックインデックス名を指定します。
structuredTypeKey の値を Log Record Fields トピックに記載されている任意のフィールドに設定できますが、構造タイプの前に来る一覧に最も便利なフィールドが表示されます。
structuredTypeKey: kubernetes.labels.<key> の例
以下と仮定します。
- クラスターが、apache および google という 2 つの異なる形式で JSON ログを生成するアプリケーション Pod を実行している。
-
ユーザーはこれらのアプリケーション Pod に
logFormat=apacheとlogFormat=googleのラベルを付ける。 -
以下のスニペットを
ClusterLogForwarderCR YAML ファイルで使用する。
outputDefaults:
elasticsearch:
structuredTypeKey: kubernetes.labels.logFormat 1
structuredTypeName: nologformat
pipelines:
- inputRefs: <application>
outputRefs: default
parse: json 2
この場合は、以下の構造化ログレコードが app-apache-write インデックスに送信されます。
{
"structured":{"name":"fred","home":"bedrock"},
"kubernetes":{"labels":{"logFormat": "apache", ...}}
}
また、以下の構造化ログレコードは app-google-write インデックスに送信されます。
{
"structured":{"name":"wilma","home":"bedrock"},
"kubernetes":{"labels":{"logFormat": "google", ...}}
}A structuredTypeKey: openshift.labels.<key> の例
以下のスニペットを ClusterLogForwarder CR YAML ファイルで使用すると仮定します。
outputDefaults:
elasticsearch:
structuredTypeKey: openshift.labels.myLabel 1
structuredTypeName: nologformat
pipelines:
- name: application-logs
inputRefs:
- application
- audit
outputRefs:
- elasticsearch-secure
- default
parse: json
labels:
myLabel: myValue 2
この場合は、以下の構造化ログレコードが app-myValue-write インデックスに送信されます。
{
"structured":{"name":"fred","home":"bedrock"},
"openshift":{"labels":{"myLabel": "myValue", ...}}
}その他の考慮事項
- 構造化されたレコードの Elasticsearch インデックス は、構造化型の前に app-を、後ろに-write を追加して設定されます。
- 非構造化レコードは、構造化されたインデックスに送信されません。これらは、通常アプリケーション、インフラストラクチャー、または監査インデックスでインデックス化されます。
-
空でない構造化タイプがない場合は、unstructured レコードを
structuredフィールドなしで転送します。
過剰なインデックスで Elasticsearch を読み込まないようにすることが重要です。各アプリケーションや namespace ごとにではなく、個別のログ形式 のみに特定の構造化タイプを使用します。たとえば、ほとんどの Apache アプリケーションは、LogApache などの同じ JSON ログ形式と構造化タイプを使用します。
3.2.9.3. JSON ログの Elasticsearch ログストアへの転送
Elasticsearch ログストアの場合は、JSON ログエントリーが異なるスキーマに従う場合、各 JSON スキーマを 1 つの出力定義にグループ化するように ClusterLogForwarder カスタムリソース (CR) を設定します。これにより、Elasticsearch はスキーマごとに個別のインデックスを使用します。
異なるスキーマを同じインデックスに転送するとタイプの競合やカーディナリティーの問題を引き起こす可能性があるため、データを Elasticsearch ストアに転送する前にこの設定を実行する必要があります。
インデックスが多すぎることが原因のパフォーマンスの問題を回避するには、共通のスキーマに標準化して使用できるスキーマの数を保持することを検討してください。
手順
以下のスニペットを
ClusterLogForwarderCR YAML ファイルに追加します。outputDefaults: elasticsearch: structuredTypeKey: <log record field> structuredTypeName: <name> pipelines: - inputRefs: - application outputRefs: default parse: json-
オプション: Configuring JSON log data for Elasticsearch で前述しているように、
structuredTypeKeyを使用してログレコードフィールドのいずれかを指定します。それ以外の場合は、この行を削除します。 オプション: Configuring JSON log data for Elasticsearch で前述しているように
structuredTypeNameを使用して<name>を指定します。それ以外の場合は、この行を削除します。重要JSON ログを解析するには、
structuredTypeKeyまたはstructuredTypeNameか、structuredTypeKeyとstructuredTypeNameの両方を設定する必要があります。-
inputRefsの場合は、application、infrastructureまたはauditなどのパイプラインを使用して転送するログタイプを指定します。 -
parse: json要素をパイプラインに追加します。 CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
Red Hat OpenShift Logging Operator は Fluentd Pod を再デプロイします。ただし、再デプロイが完了しない場合は、Fluentd Pod を削除して、強制的に再デプロイされるようにします。
$ oc delete pod --selector logging-infra=collector
関連情報
3.2.10. Kubernetes イベントの収集および保存
OpenShift Container Platform イベントルーターは、Kubernetes イベントを監視し、それらをロギングシステムによって収集できるようにログに記録する pod です。イベントルーターは手動でデプロイする必要があります。
イベントルーターはすべてのプロジェクトからイベントを収集し、それらを STDOUT に書き込みます。次に、コレクターはそれらのイベントを ClusterLogForwarder カスタムリソース (CR) で定義されたストアに転送します。
イベントルーターは追加の負荷を Fluentd に追加し、処理できる他のログメッセージの数に影響を与える可能性があります。
3.2.10.1. イベントルーターのデプロイおよび設定
以下の手順を使用してイベントルーターをクラスターにデプロイします。イベントルーターを openshift-logging プロジェクトに常にデプロイし、クラスター全体でイベントが収集されるようにする必要があります。
以下のテンプレートオブジェクトは、イベントルーターに必要なサービスアカウント、クラスターロールおよびクラスターロールバインディングを作成します。テンプレートはイベントルーター Pod も設定し、デプロイします。このテンプレートは変更せずに使用するか、デプロイメントオブジェクトの CPU およびメモリー要求を変更できます。
前提条件
- サービスアカウントを作成し、クラスターロールバインディングを更新するには、適切なパーミッションが必要です。たとえば、以下のテンプレートを、cluster-admin ロールを持つユーザーで実行できます。
- Red Hat OpenShift のロギングサブシステムをインストールする必要があります。
手順
イベントルーターのテンプレートを作成します。
kind: Template apiVersion: template.openshift.io/v1 metadata: name: eventrouter-template annotations: description: "A pod forwarding kubernetes events to OpenShift Logging stack." tags: "events,EFK,logging,cluster-logging" objects: - kind: ServiceAccount 1 apiVersion: v1 metadata: name: eventrouter namespace: ${NAMESPACE} - kind: ClusterRole 2 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: event-reader rules: - apiGroups: [""] resources: ["events"] verbs: ["get", "watch", "list"] - kind: ClusterRoleBinding 3 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: event-reader-binding subjects: - kind: ServiceAccount name: eventrouter namespace: ${NAMESPACE} roleRef: kind: ClusterRole name: event-reader - kind: ConfigMap 4 apiVersion: v1 metadata: name: eventrouter namespace: ${NAMESPACE} data: config.json: |- { "sink": "stdout" } - kind: Deployment 5 apiVersion: apps/v1 metadata: name: eventrouter namespace: ${NAMESPACE} labels: component: "eventrouter" logging-infra: "eventrouter" provider: "openshift" spec: selector: matchLabels: component: "eventrouter" logging-infra: "eventrouter" provider: "openshift" replicas: 1 template: metadata: labels: component: "eventrouter" logging-infra: "eventrouter" provider: "openshift" name: eventrouter spec: serviceAccount: eventrouter containers: - name: kube-eventrouter image: ${IMAGE} imagePullPolicy: IfNotPresent resources: requests: cpu: ${CPU} memory: ${MEMORY} volumeMounts: - name: config-volume mountPath: /etc/eventrouter volumes: - name: config-volume configMap: name: eventrouter parameters: - name: IMAGE 6 displayName: Image value: "registry.redhat.io/openshift-logging/eventrouter-rhel8:v0.4" - name: CPU 7 displayName: CPU value: "100m" - name: MEMORY 8 displayName: Memory value: "128Mi" - name: NAMESPACE displayName: Namespace value: "openshift-logging" 9- 1
- イベントルーターの
openshift-loggingプロジェクトでサービスアカウントを作成します。 - 2
- ClusterRole を作成し、クラスター内のイベントを監視します。
- 3
- ClusterRoleBinding を作成し、ClusterRole をサービスアカウントにバインドします。
- 4
openshift-loggingプロジェクトで設定マップを作成し、必要なconfig.jsonファイルを生成します。- 5
openshift-loggingプロジェクトでデプロイメントを作成し、イベントルーター Pod を生成し、設定します。- 6
v0.4などのタグで識別されるイメージを指定します。- 7
- イベントルーター Pod に割り当てる CPU の最小量を指定します。デフォルトは
100mに設定されます。 - 8
- イベントルーター Pod に割り当てるメモリーの最小量を指定します。デフォルトは
128Miに設定されます。 - 9
- オブジェクトをインストールする
openshift-loggingプロジェクトを指定します。
以下のコマンドを使用してテンプレートを処理し、これを適用します。
$ oc process -f <templatefile> | oc apply -n openshift-logging -f -
以下に例を示します。
$ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -
出力例
serviceaccount/eventrouter created clusterrole.authorization.openshift.io/event-reader created clusterrolebinding.authorization.openshift.io/event-reader-binding created configmap/eventrouter created deployment.apps/eventrouter created
イベントルーターが
openshift-loggingプロジェクトにインストールされていることを確認します。新規イベントルーター Pod を表示します。
$ oc get pods --selector component=eventrouter -o name -n openshift-logging
出力例
pod/cluster-logging-eventrouter-d649f97c8-qvv8r
イベントルーターによって収集されるイベントを表示します。
$ oc logs <cluster_logging_eventrouter_pod> -n openshift-logging
以下に例を示します。
$ oc logs cluster-logging-eventrouter-d649f97c8-qvv8r -n openshift-logging
出力例
{"verb":"ADDED","event":{"metadata":{"name":"openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","namespace":"openshift-service-catalog-removed","selfLink":"/api/v1/namespaces/openshift-service-catalog-removed/events/openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","uid":"787d7b26-3d2f-4017-b0b0-420db4ae62c0","resourceVersion":"21399","creationTimestamp":"2020-09-08T15:40:26Z"},"involvedObject":{"kind":"Job","namespace":"openshift-service-catalog-removed","name":"openshift-service-catalog-controller-manager-remover","uid":"fac9f479-4ad5-4a57-8adc-cb25d3d9cf8f","apiVersion":"batch/v1","resourceVersion":"21280"},"reason":"Completed","message":"Job completed","source":{"component":"job-controller"},"firstTimestamp":"2020-09-08T15:40:26Z","lastTimestamp":"2020-09-08T15:40:26Z","count":1,"type":"Normal"}}また、Elasticsearch
infraインデックスを使用してインデックスパターンを作成し、Kibana を使用してイベントを表示することもできます。
3.2.11. OpenShift Logging の更新
3.2.11.1. サポート対象バージョン
バージョンの互換性とサポート情報については、Red Hat OpenShift Container Platform Life Cycle Policy を参照してください。
OpenShift Container Platform バージョン 4.6 以前でクラスターロギングから OpenShift Logging 5.x にアップグレードするには、OpenShift Container Platform クラスターをバージョン 4.7 または 4.8 に更新します。次に、以下の Operator を更新します。
- Elasticsearch Operator 4.x から OpenShift Elasticsearch Operator 5.x へ
- Cluster Logging Operator 4.x から Red Hat OpenShift Logging Operator 5.x へ
以前のバージョンの OpenShift Logging から現行バージョンにアップグレードするには、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator を現行バージョンに更新します。
3.2.11.2. Logging を現在のバージョンに更新する
Logging を現在のバージョンに更新するには、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator のサブスクリプションを変更します。
Red Hat OpenShift Logging Operator を更新する前に OpenShift Elasticsearch Operator を更新する必要があります。また、両方の Operator を同じバージョンに更新する必要があります。
Operator を間違った順序で更新すると、Kibana は更新されず、Kibana カスタムリソース (CR) は作成されません。この問題を回避するには、Red Hat OpenShift Logging Operator Pod を削除します。Red Hat OpenShift Logging Operator Pod が再デプロイされると、Kibana CR が作成され、Kibana が再度利用可能になります。
前提条件
- OpenShift Container Platform バージョンが 4.7 以降である。
ロギングステータスは正常です。
-
すべての Pod が
Ready状態にある。 - Elasticsearch クラスターが正常である。
-
すべての Pod が
- Elasticsearch および Kibana データのバックアップが作成されている。
手順
OpenShift Elasticsearch Operator を更新します。
- Web コンソールで Operators → Installed Operators をクリックします。
-
openshift-operators-redhatプロジェクトを選択します。 - OpenShift Elasticsearch Operator をクリックします。
- Subscription → Channel をクリックします。
- Change Subscription Update Channel ウィンドウで stable-5.x を選択し、Save をクリックします。
- 数秒待ってから Operators → Installed Operators をクリックします。
- OpenShift Elasticsearch Operator のバージョンが 5.x.x であることを確認します。
- Status フィールドで Succeeded を報告するのを待機します。
Red Hat OpenShift Logging Operator を更新します。
- Web コンソールで Operators → Installed Operators をクリックします。
-
openshift-loggingプロジェクトを選択します。 - Red Hat OpenShift Logging Operator をクリックします。
- Subscription → Channel をクリックします。
- Change Subscription Update Channel ウィンドウで stable-5.x を選択し、Save をクリックします。
- 数秒待ってから Operators → Installed Operators をクリックします。
- Red Hat OpenShift Logging Operator のバージョンが 5.y.z であることを確認します。
- Status フィールドで Succeeded を報告するのを待機します。
ロギングコンポーネントを確認します。
すべての Elasticsearch Pod が Ready ステータスであることを確認します。
$ oc get pod -n openshift-logging --selector component=elasticsearch
出力例
NAME READY STATUS RESTARTS AGE elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk 2/2 Running 0 31m elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk 2/2 Running 0 30m elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc 2/2 Running 0 29m
Elasticsearch クラスターが正常であることを確認します。
$ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health
{ "cluster_name" : "elasticsearch", "status" : "green", }Elasticsearch cron ジョブが作成されていることを確認します。
$ oc project openshift-logging
$ oc get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE elasticsearch-im-app */15 * * * * False 0 <none> 56s elasticsearch-im-audit */15 * * * * False 0 <none> 56s elasticsearch-im-infra */15 * * * * False 0 <none> 56s
ログストアが 5.x に更新され、インデックスが
greenであることを確認します。$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices
出力に
app-00000x、infra-00000x、audit-00000x、.securityインデックス が含まれることを確認します。例3.2 緑色のステータスのインデックスを含む出力例
Tue Jun 30 14:30:54 UTC 2020 health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open infra-000008 bnBvUFEXTWi92z3zWAzieQ 3 1 222195 0 289 144 green open infra-000004 rtDSzoqsSl6saisSK7Au1Q 3 1 226717 0 297 148 green open infra-000012 RSf_kUwDSR2xEuKRZMPqZQ 3 1 227623 0 295 147 green open .kibana_7 1SJdCqlZTPWlIAaOUd78yg 1 1 4 0 0 0 green open infra-000010 iXwL3bnqTuGEABbUDa6OVw 3 1 248368 0 317 158 green open infra-000009 YN9EsULWSNaxWeeNvOs0RA 3 1 258799 0 337 168 green open infra-000014 YP0U6R7FQ_GVQVQZ6Yh9Ig 3 1 223788 0 292 146 green open infra-000015 JRBbAbEmSMqK5X40df9HbQ 3 1 224371 0 291 145 green open .orphaned.2020.06.30 n_xQC2dWQzConkvQqei3YA 3 1 9 0 0 0 green open infra-000007 llkkAVSzSOmosWTSAJM_hg 3 1 228584 0 296 148 green open infra-000005 d9BoGQdiQASsS3BBFm2iRA 3 1 227987 0 297 148 green open infra-000003 1-goREK1QUKlQPAIVkWVaQ 3 1 226719 0 295 147 green open .security zeT65uOuRTKZMjg_bbUc1g 1 1 5 0 0 0 green open .kibana-377444158_kubeadmin wvMhDwJkR-mRZQO84K0gUQ 3 1 1 0 0 0 green open infra-000006 5H-KBSXGQKiO7hdapDE23g 3 1 226676 0 295 147 green open infra-000001 eH53BQ-bSxSWR5xYZB6lVg 3 1 341800 0 443 220 green open .kibana-6 RVp7TemSSemGJcsSUmuf3A 1 1 4 0 0 0 green open infra-000011 J7XWBauWSTe0jnzX02fU6A 3 1 226100 0 293 146 green open app-000001 axSAFfONQDmKwatkjPXdtw 3 1 103186 0 126 57 green open infra-000016 m9c1iRLtStWSF1GopaRyCg 3 1 13685 0 19 9 green open infra-000002 Hz6WvINtTvKcQzw-ewmbYg 3 1 228994 0 296 148 green open infra-000013 KR9mMFUpQl-jraYtanyIGw 3 1 228166 0 298 148 green open audit-000001 eERqLdLmQOiQDFES1LBATQ 3 1 0 0 0 0
ログコレクターが以下に更新されていることを確認します。
$ oc get ds collector -o json | grep collector
出力に
collectortコンテナーが含まれていることを確認します。"containerName": "collector"
Kibana CRD を使用してログビジュアライザーが 5.x に更新されていることを確認します。
$ oc get kibana kibana -o json
出力に
readyステータスの Kibana Pod が含まれることを確認します。例3.3 準備状態にある Kibana Pod の出力例
[ { "clusterCondition": { "kibana-5fdd766ffd-nb2jj": [ { "lastTransitionTime": "2020-06-30T14:11:07Z", "reason": "ContainerCreating", "status": "True", "type": "" }, { "lastTransitionTime": "2020-06-30T14:11:07Z", "reason": "ContainerCreating", "status": "True", "type": "" } ] }, "deployment": "kibana", "pods": { "failed": [], "notReady": [] "ready": [] }, "replicaSets": [ "kibana-5fdd766ffd" ], "replicas": 1 } ]
3.2.12. クラスターダッシュボードの表示
OpenShift Container Platform Web コンソールの Logging/Elasticsearch Nodes および Openshift Logging ダッシュボードは、 Elasticsearch インスタンスや、問題の発生防止および診断に使用できる個別の Elasticsearch ノードについての詳細情報を表示します。
OpenShift Logging ダッシュボードには、クラスターリソース、ガベージコレクション、クラスターのシャード、Fluentd 統計など、クラスターレベルでの Elasticsearch インスタンスについての詳細を表示するチャートが含まれます。
Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch インスタンスの詳細を表示するチャートが含まれます。これらのチャートの多くはノードレベルのものであり、これには、インデックス、シャード、リソースなどの詳細が含まれます。
3.2.12.1. Elastisearch および Openshift Logging ダッシュボードへのアクセス
OpenShift Container Platform Web コンソールで Logging/Elasticsearch Nodes および Openshift Logging ダッシュボードを表示できます。
手順
ダッシュボードを起動するには、以下を実行します。
- OpenShift Container Platform Web コンソールで、Observe → Dashboards をクリックします。
Dashboards ページで、Dashboard メニューから Logging/Elasticsearch Nodes または Openshift Logging を選択します。
Logging/Elasticsearch Nodes ダッシュボードの場合は、表示する必要のある Elasticsearch ノードを選択し、データの解像度を設定できます。
適切なダッシュボードが表示され、データの複数のチャートが表示されます。
- 必要に応じて、Time Range メニューおよび Refresh Interval メニューから、データを表示するさまざまな時間の範囲またはデータのリフレッシュレートを選択します。
ダッシュボードチャートについての詳細は、About the OpenShift Logging dashboard および About the Logging/Elastisearch Nodes dashboard を参照してください。
3.2.12.2. OpenShift Logging ダッシュボードについて
OpenShift Logging ダッシュボードには、クラスターレベルで Elasticsearch インスタンスの詳細を表示するチャートが含まれており、これを使用して問題を診断し、予測できます。
表3.10 OpenShift Logging チャート
| メトリック | 説明 |
|---|---|
| Elastic Cluster Status (Elastic Cluster のステータス) | Elasticsearch の現行ステータス:
|
| Elastic Nodes (Elastic ノード) | Elasticsearch インスタンス内の Elasticsearch ノードの合計数。 |
| Elastic Shards (Elastic シャード) | Elasticsearch インスタンス内の Elasticsearch シャードの合計数。 |
| Elastic Documents (Elastic ドキュメント) | Elasticsearch インスタンス内の Elasticsearch ドキュメントの合計数。 |
| Total Index Size on Disk (ディスク上の合計インデックスサイズ) | Elasticsearch インデックスに使用されるディスク容量の合計。 |
| Elastic Pending Tasks (Elastic の保留中のタスク) | インデックスの作成、インデックスのマッピング、シャードの割り当て、シャードの失敗など、完了していない Elasticsearch 変更の合計数。 |
| Elastic JVM GC time (Elastic JVM GC 時間) | JVM がクラスターでの Elasticsearch ガベージコレクション操作の実行に費した時間。 |
| Elastic JVM GC Rate (Elastic JVM GC レート) | JVM が 1 秒ごとにガベージアクティビティーを実行する合計回数。 |
| Elastic Query/Fetch Latency Sum (Elastic クエリー/フェッチのレイテンシーの合計) |
通常、フェッチレイテンシーの時間はクエリーレイテンシーよりも短くなります。フェッチレイテンシーが一貫して増加する場合、これはディスクの速度の低下、データの増加、または結果が多すぎる大規模な要求があることを示している可能性があります。 |
| Elastic Query Rate (Elastic クエリーレート) | 各 Elasticsearch ノードの 1 秒あたりに Elasticsearch インスタンスに対して実行されたクエリーの合計。 |
| CPU | コンポーネントごとに表示される Elasticsearch、Fluentd、および Kibana によって使用される CPU の量。 |
| Elastic JVM Heap Used (Elastic JVM ヒープの使用) | 使用される JVM メモリーの量。正常なクラスターでは、JVM ガベージコレクションによってメモリーが解放されると、グラフは定期的な低下を示します。 |
| Elasticsearch Disk Usage (Elasticsearch ディスクの使用) | 各 Elasticsearch ノードの Elasticsearch インスタンスによって使用されるディスク容量の合計。 |
| File Descriptors In Use (使用中のファイル記述子) | Elasticsearch、Fluentd、および Kibana によって使用されるファイル記述子の合計数。 |
| FluentD emit count (Fluentd の生成数) | Fluentd デフォルト出力の 1 秒あたりの Fluentd メッセージの合計数およびデフォルト出力の再試行数。 |
| FluentD Buffer Availability (Fluentd バッファーの可用性) | チャンクに使用できる Fluentd バッファーのパーセント。バッファーが一杯になると、Fluentd が受信するログ数を処理できないことを示す可能性があります。 |
| Elastic rx bytes (Elastic rx バイト) | Elasticsearch が FluentD、Elasticsearch ノード、およびその他のソースから受信した合計バイト数。 |
| Elastic Index Failure Rate (Elastic インデックス失敗率) | Elasticsearch インデックスで失敗した 1 秒あたりの合計回数。レートが高い場合は、インデックスに問題があることを示す可能性があります。 |
| FluentD Output Error Rate (Fluentd 出力エラー率) | FluentD がログの出力に失敗する 1 秒あたりの合計回数。 |
3.2.12.3. Logging/Elasticsearch ノードダッシュボードのチャート
Logging/Elasticsearch Nodes ダッシュボードには、追加の診断に使用できる Elasticsearch インスタンスの詳細を表示するチャートが含まれます。これらのチャートの多くはノードレベルのものです。
- Elasticsearch ステータス
- Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch インスタンスのステータスに関する以下のチャートが含まれます。
表3.11 Elasticsearch ステータスフィールド
| メトリック | 説明 |
|---|---|
| Cluster status (クラスターステータス) | Elasticsearch の green、yellow、および red ステータスを使用する、選択された期間におけるクラスターの正常性ステータス。
|
| Cluster nodes (クラスターノード) | クラスター内の Elasticsearch ノードの合計数。 |
| Cluster data nodes (クラスターデータノード) | クラスター内の Elasticsearch データノードの数。 |
| Cluster pending tasks (クラスターの保留中のタスク) | 終了しておらず、クラスターキューで待機中のクラスター状態変更の数。たとえば、インデックスの作成、インデックスの削除、シャードの割り当てなどがあります。増加傾向は、クラスターが変更に対応できないことを示します。 |
- Elasticsearch クラスターインデックスシャードのステータス
- 各 Elasticsearch インデックスは、永続化されたデータの基本単位である 1 つ以上のシャードの論理グループです。インデックスシャードには、プライマリーシャードとレプリカシャードの 2 つのタイプがあります。ドキュメントがインデックスにインデックス化されると、これはプライマリーシャードのいずれかに保存され、そのシャードのすべてのレプリカにコピーされます。プライマリーシャードの数はインデックスの作成時に指定され、この数はインデックスの有効期間に変更することはできません。レプリカシャードの数はいつでも変更できます。
インデックスシャードは、ライフサイクルフェーズまたはクラスターで発生するイベントに応じて複数の状態に切り替わります。シャードが検索およびインデックス要求を実行できる場合、シャードはアクティブになります。シャードがこれらの要求を実行できない場合、シャードは非アクティブになります。シャードが初期化、再割り当て、未割り当てなどの状態にある場合は、シャードが非アクティブになる可能性があります。
インデックスシャードは、データの物理表現であるインデックスセグメントと呼ばれる数多くの小さな内部ブロックで設定されます。インデックスセグメントは、Lucene が新たにインデックス化されたデータをコミットしたときに作成される比較的小さく、イミュータブルな Lucene インデックスです。Lucene (Elasticsearch によって使用される検索ライブラリー) は、バックグラウンドでインデックスセグメントをより大きなセグメントにマージし、セグメントの合計数を低い状態に維持します。セグメントをマージするプロセスが新規セグメントが作成される速度よりも遅くなる場合は、問題があることを示す可能性があります。
Lucene が検索操作などのデータ操作を実行する場合、Lucene は関連するインデックスのインデックスセグメントに対して操作を実行します。そのため、各セグメントには、メモリーにロードされ、マップされる特定のデータ構造が含まれます。インデックスマッピングは、セグメントデータ構造で使用されるメモリーに大きく影響を与える可能性があります。
Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch インデックスシャードに関する以下のチャートが含まれます。
表3.12 Elasticsearch クラスターのシャードステータスのチャート
| メトリック | 説明 |
|---|---|
| Cluster active shards (クラスターのアクティブシャード) | クラスターにおけるアクティブなプライマリーシャードの数と、レプリカを含むシャードの合計数。シャードの数が大きくなると、クラスターのパフォーマンスが低下し始める可能性があります。 |
| Cluster initializing shards (クラスターの初期化シャード) | クラスターのアクティブではないシャードの数。アクティブではないシャードは、初期化され、別のノードに再配置されるているシャードや、割り当てられていないシャードを指します。通常、クラスターには短期間アクティブではないシャードがあります。長期間にわたってアクティブではないシャードの数が増える場合は、問題があることを示す可能性があります。 |
| Cluster relocating shards (クラスターの再配置シャード) | Elasticsearch が新規ノードに再配置されているシャードの数。Elasticsearch は、ノードでのメモリー使用率が高い場合や新規ノードがクラスターに追加された後などの複数の理由によりノードを再配置します。 |
| Cluster unassigned shards (クラスター未割り当てシャード) | 未割り当てのシャードの数。Elasticsearch シャードは、新規インデックスの追加やノードの障害などの理由で割り当てられない可能性があります。 |
- Elasticsearch ノードメトリクス
- 各 Elasticsearch ノードには、タスクの処理に使用できるリソースの量に制限があります。すべてのリソースが使用中で、Elasticsearch が新規タスクの実行を試行する場合、Elasticsearch は一部のリソースが利用可能になるまでタスクをキューに入れます。
Logging/Elasticsearch Nodes ダッシュボードには、選択されたノードのリソース使用状況に関する以下のチャートと Elasticsearch キューで待機中のタスクの数が含まれます。
表3.13 Elasticsearch ノードのメトリクスチャート
| メトリック | 説明 |
|---|---|
| ThreadPool tasks (ThreadPool タスク) | 個別のキューの待機中のタスクの数 (タスクタイプ別に表示されます)。キュー内のタスクの長期間累積した状態は、ノードリソースの不足やその他の問題があることを示す可能性があります。 |
| CPU usage (CPU の使用率) | ホストコンテナーに割り当てられる CPU の合計の割合として、選択した Elasticsearch ノードによって使用される CPU の量。 |
| メモリー使用量 | 選択した Elasticsearch ノードによって使用されるメモリー量。 |
| Disk usage (ディスク使用量) | 選択された Elasticsearch ノードのインデックスデータおよびメタデータに使用されるディスク容量の合計。 |
| Documents indexing rate (ドキュメントインデックス化レート) | ドキュメントが選択された Elasticsearch ノードでインデックス化されるレート。 |
| Indexing latency (インデックス化レイテンシー) | 選択された Elasticsearch ノードでドキュメントをインデックス化するのに必要となる時間。インデックス化レイテンシーは、JVM ヒープメモリーや全体の負荷などの多くの要素による影響を受ける可能性があります。レイテンシーが増加する場合は、インスタンス内のリソース容量が不足していることを示します。 |
| Search rate (検索レート) | 選択された Elasticsearch ノードで実行される検索要求の数。 |
| Search latency (検索レイテンシー) | 選択された Elasticsearch ノードで検索要求を完了するのに必要となる時間。検索レイテンシーは、数多くの要因の影響を受ける可能性があります。レイテンシーが増加する場合は、インスタンス内のリソース容量が不足していることを示します。 |
| Documents count (with replicas)(ドキュメント数 (レプリカ使用)) | 選択された Elasticsearch ノードに保管される Elasticsearch ドキュメントの数。これには、ノードで割り当てられるプライマリーシャードとレプリカシャードの両方に保存されるドキュメントが含まれます。 |
| Documents deleting rate (ドキュメントの削除レート) | 選択された Elasticsearch ノードに割り当てられるいずれかのインデックスシャードから削除される Elasticsearch ドキュメントの数。 |
| Documents merging rate (ドキュメントのマージレート) | 選択された Elasticsearch ノードに割り当てられるインデックスシャードのいずれかでマージされる Elasticsearch ドキュメントの数。 |
- Elasticsearch ノードフィールドデータ
- Fielddata はインデックスの用語の一覧を保持する Elasticsearch データ構造であり、JVM ヒープに保持されます。fielddata のビルドはコストのかかる操作であるため、Elasticsearch は fielddata 構造をキャッシュします。Elasticsearch は、基礎となるインデックスセグメントが削除されたり、マージされる場合や、すべての fielddata キャッシュに JVM HEAP メモリーが十分にない場合に、fielddata キャッシュをエビクトできます。
Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch fielddata に関する以下のチャートが含まれます。
表3.14 Elasticsearch ノードフィールドデータチャート
| メトリック | 説明 |
|---|---|
| Fielddata memory size (Fielddata メモリーサイズ) | 選択された Elasticsearch ノードの fielddata キャッシュに使用される JVM ヒープの量。 |
| Fielddata evictions (Fielddata エビクション) | 選択された Elasticsearch ノードから削除された fielddata 構造の数。 |
- Elasticsearch ノードのクエリーキャッシュ
- インデックスに保存されているデータが変更されない場合、検索クエリーの結果は Elasticsearch で再利用できるようにノードレベルのクエリーキャッシュにキャッシュされます。
Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch ノードのクエリーキャッシュに関する以下のチャートが含まれます。
表3.15 Elasticsearch ノードのクエリーチャート
| メトリック | 説明 |
|---|---|
| Query cache size (クエリーキャッシュサイズ) | 選択された Elasticsearch ノードに割り当てられるすべてのシャードのクエリーキャッシュに使用されるメモリーの合計量。 |
| Query cache evictions (クエリーキャッシュエビクション) | 選択された Elasticsearch ノードでのクエリーキャッシュのエビクション数。 |
| Query cache hits (クエリーキャッシュヒット) | 選択された Elasticsearch ノードでのクエリーキャッシュのヒット数。 |
| Query cache misses (クエリーキャッシュミス) | 選択された Elasticsearch ノードでのクエリーキャッシュのミス数。 |
- Elasticsearch インデックスのスロットリング
- ドキュメントのインデックスを作成する場合、Elasticsearch はデータの物理表現であるインデックスセグメントにドキュメントを保存します。同時に、Elasticsearch はリソースの使用を最適化する方法として、より小さなセグメントをより大きなセグメントに定期的にマージします。インデックス処理がセグメントをマージする機能よりも高速になる場合は、マージプロセスが十分前もって終了せずに、検索やパフォーマンスに関連した問題が生じる可能性があります。この状況を防ぐために、Elasticsearch はインデックスをスロットリングします。通常、インデックスに割り当てられるスレッド数を 1 つのスレッドに減らすことで制限できます。
Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch インデックスのスロットリングに関する以下のチャートが含まれます。
表3.16 インデックススロットリングチャート
| メトリック | 説明 |
|---|---|
| Indexing throttling (インデックスのスロットリング) | Elasticsearch が選択された Elasticsearch ノードでインデックス操作をスロットリングしている時間。 |
| Merging throttling (マージのスロットリング) | Elasticsearch が選択された Elasticsearch ノードでセグメントのマージ操作をスロットリングしている時間。 |
- ノード JVM ヒープの統計
- Logging/Elasticsearch Nodes ダッシュボードには、JVM ヒープ操作に関する以下のチャートが含まれます。
表3.17 JVM ヒープ統計チャート
| メトリック | 説明 |
|---|---|
| Heap used (ヒープの使用) | 選択された Elasticsearch ノードで使用される割り当て済みの JVM ヒープ領域の合計。 |
| GC count (GC 数) | 新旧のガベージコレクションによって、選択された Elasticsearch ノードで実行されてきたガベージコレクション操作の数。 |
| GC time (GC 時間) | JVM が、新旧のガベージコレクションによって選択された Elasticsearch ノードでガベージコレクションを実行してきた時間。 |
3.2.13. ロギングのトラブルシューティング
3.2.13.1. OpenShift Logging ステータスの表示
Red Hat OpenShift Logging Operator のステータスおよびいくつかのロギングサブシステムコンポーネントを表示できます。
3.2.13.1.1. Red Hat OpenShift Logging Operator のステータス表示
Red Hat OpenShift Logging Operator のステータスを表示できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
openshift-loggingプロジェクトに切り替えます。$ oc project openshift-logging
OpenShift Logging のステータスを表示するには、以下を実行します。
OpenShift Logging のステータスを取得します。
$ oc get clusterlogging instance -o yaml
出力例
apiVersion: logging.openshift.io/v1 kind: ClusterLogging .... status: 1 collection: logs: fluentdStatus: daemonSet: fluentd 2 nodes: fluentd-2rhqp: ip-10-0-169-13.ec2.internal fluentd-6fgjh: ip-10-0-165-244.ec2.internal fluentd-6l2ff: ip-10-0-128-218.ec2.internal fluentd-54nx5: ip-10-0-139-30.ec2.internal fluentd-flpnn: ip-10-0-147-228.ec2.internal fluentd-n2frh: ip-10-0-157-45.ec2.internal pods: failed: [] notReady: [] ready: - fluentd-2rhqp - fluentd-54nx5 - fluentd-6fgjh - fluentd-6l2ff - fluentd-flpnn - fluentd-n2frh logstore: 3 elasticsearchStatus: - ShardAllocationEnabled: all cluster: activePrimaryShards: 5 activeShards: 5 initializingShards: 0 numDataNodes: 1 numNodes: 1 pendingTasks: 0 relocatingShards: 0 status: green unassignedShards: 0 clusterName: elasticsearch nodeConditions: elasticsearch-cdm-mkkdys93-1: nodeCount: 1 pods: client: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c data: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c master: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c visualization: 4 kibanaStatus: - deployment: kibana pods: failed: [] notReady: [] ready: - kibana-7fb4fd4cc9-f2nls replicaSets: - kibana-7fb4fd4cc9 replicas: 1
3.2.13.1.1.1. 状態メッセージ (condition message) のサンプル
以下は、OpenShift Logging インスタンスの Status.Nodes セクションからの一部の状態メッセージの例です。
以下のようなステータスメッセージは、ノードが設定された低基準値を超えており、シャードがこのノードに割り当てられないことを示します。
出力例
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T15:57:22Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
be allocated on this node.
reason: Disk Watermark Low
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-clientdatamaster-0-1
upgradeStatus: {}
以下のようなステータスメッセージは、ノードが設定された高基準値を超えており、シャードが他のノードに移動させられることを示します。
出力例
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T16:04:45Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
from this node.
reason: Disk Watermark High
status: "True"
type: NodeStorage
deploymentName: cluster-logging-operator
upgradeStatus: {}
以下のようなステータスメッセージは、CR の Elasticsearch ノードセレクターがクラスターのいずれのノードにも一致しないことを示します。
出力例
Elasticsearch Status:
Shard Allocation Enabled: shard allocation unknown
Cluster:
Active Primary Shards: 0
Active Shards: 0
Initializing Shards: 0
Num Data Nodes: 0
Num Nodes: 0
Pending Tasks: 0
Relocating Shards: 0
Status: cluster health unknown
Unassigned Shards: 0
Cluster Name: elasticsearch
Node Conditions:
elasticsearch-cdm-mkkdys93-1:
Last Transition Time: 2019-06-26T03:37:32Z
Message: 0/5 nodes are available: 5 node(s) didn't match node selector.
Reason: Unschedulable
Status: True
Type: Unschedulable
elasticsearch-cdm-mkkdys93-2:
Node Count: 2
Pods:
Client:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:
Data:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:
Master:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:
以下のようなステータスメッセージは、要求された PVC が PV にバインドされないことを示します。
出力例
Node Conditions:
elasticsearch-cdm-mkkdys93-1:
Last Transition Time: 2019-06-26T03:37:32Z
Message: pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
Reason: Unschedulable
Status: True
Type: Unschedulable
以下のようなステータスメッセージは、ノードセレクターがいずれのノードにも一致しないため、Fluentd Pod をスケジュールできないことを示します。
出力例
Status:
Collection:
Logs:
Fluentd Status:
Daemon Set: fluentd
Nodes:
Pods:
Failed:
Not Ready:
Ready:
3.2.13.1.2. ロギングサブシステムコンポーネントのステータスの表示
いくつかのロギングサブシステムコンポーネントのステータスを表示できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
openshift-loggingプロジェクトに切り替えます。$ oc project openshift-logging
Red Hat OpenShift 環境のロギングサブシステムのステータスを表示します。
$ oc describe deployment cluster-logging-operator
出力例
Name: cluster-logging-operator .... Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable .... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 62m deployment-controller Scaled up replica set cluster-logging-operator-574b8987df to 1----
ロギングサブシステムレプリカセットのステータスを表示します。
レプリカセットの名前を取得します。
出力例
$ oc get replicaset
出力例
NAME DESIRED CURRENT READY AGE cluster-logging-operator-574b8987df 1 1 1 159m elasticsearch-cdm-uhr537yu-1-6869694fb 1 1 1 157m elasticsearch-cdm-uhr537yu-2-857b6d676f 1 1 1 156m elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd 1 1 1 155m kibana-5bd5544f87 1 1 1 157m
レプリカセットのステータスを取得します。
$ oc describe replicaset cluster-logging-operator-574b8987df
出力例
Name: cluster-logging-operator-574b8987df .... Replicas: 1 current / 1 desired Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed .... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 66m replicaset-controller Created pod: cluster-logging-operator-574b8987df-qjhqv----
3.2.13.2. Elasticsearch ログストアのステータスの表示
OpenShift Elasticsearch Operator のステータスや、数多くの Elasticsearch コンポーネントを表示できます。
3.2.13.2.1. ログストアのステータスの表示
ログストアのステータスを表示できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
openshift-loggingプロジェクトに切り替えます。$ oc project openshift-logging
ステータスを表示するには、以下を実行します。
ログストアインスタンスの名前を取得します。
$ oc get Elasticsearch
出力例
NAME AGE elasticsearch 5h9m
ログストアのステータスを取得します。
$ oc get Elasticsearch <Elasticsearch-instance> -o yaml
以下に例を示します。
$ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml
出力には、以下のような情報が含まれます。
出力例
status: 1 cluster: 2 activePrimaryShards: 30 activeShards: 60 initializingShards: 0 numDataNodes: 3 numNodes: 3 pendingTasks: 0 relocatingShards: 0 status: green unassignedShards: 0 clusterHealth: "" conditions: [] 3 nodes: 4 - deploymentName: elasticsearch-cdm-zjf34ved-1 upgradeStatus: {} - deploymentName: elasticsearch-cdm-zjf34ved-2 upgradeStatus: {} - deploymentName: elasticsearch-cdm-zjf34ved-3 upgradeStatus: {} pods: 5 client: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt data: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt master: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt shardAllocationEnabled: all
- 1
- 出力の
statusスタンザに、クラスターステータスのフィールドが表示されます。 - 2
- ログストアのステータス:
- アクティブなプライマリーシャードの数
- アクティブなシャードの数
- 初期化されるシャードの数
- ログストアデータノードの数。
- ログストアノードの合計数。
- 保留中のタスクの数。
-
ログストアのステータス:
green、red、yellow。 - 未割り当てのシャードの数。
- 3
- ステータス状態 (ある場合)。ログストアのステータスは、Pod が配置されていない場合にスケジューラーからの理由を示します。以下の状況に関連したイベントが表示されます。
- コンテナーログストアとプロキシーコンテナーの両方を待機中。
- ログストアコンテナーとプロキシーコンテナーの両方でコンテナーが終了している。
- Pod がスケジュール対象外である。また、いくつかの問題に関する条件も示されています。詳細は、状態メッセージのサンプル を参照してください。
- 4
upgradeStatusのあるクラスター内のログストアノード。- 5
- 'failed`、
notReadyまたはready状態の下に一覧表示された、クラスター内のログストアクライアント、データ、およびマスター Pod。
3.2.13.2.1.1. 状態メッセージ (condition message) のサンプル
以下は、Elasticsearch インスタンスの Status セクションからの一部の状態メッセージの例になります。
以下のステータスメッセージは、ノードが設定された低基準値を超えており、シャードがこのノードに割り当てられないことを示します。
status:
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T15:57:22Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
be allocated on this node.
reason: Disk Watermark Low
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-cdm-0-1
upgradeStatus: {}以下のステータスメッセージは、ノードが設定された高基準値を超えており、シャードが他のノードに移動させられることを示します。
status:
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T16:04:45Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
from this node.
reason: Disk Watermark High
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-cdm-0-1
upgradeStatus: {}以下のステータスメッセージは、CR のログストアノードセレクターがクラスターのいずれのノードにも一致しないことを示します。
status:
nodes:
- conditions:
- lastTransitionTime: 2019-04-10T02:26:24Z
message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
reason: Unschedulable
status: "True"
type: Unschedulable以下のステータスメッセージは、ログストア CR が存在しない 永続ボリューム要求 (PVC) を使用することを示します。
status:
nodes:
- conditions:
- last Transition Time: 2019-04-10T05:55:51Z
message: pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
reason: Unschedulable
status: True
type: Unschedulable以下のステータスメッセージは、ログストアクラスターには冗長性ポリシーをサポートするための十分なノードがないことを示します。
status:
clusterHealth: ""
conditions:
- lastTransitionTime: 2019-04-17T20:01:31Z
message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
add more nodes with data roles
reason: Invalid Settings
status: "True"
type: InvalidRedundancyこのステータスメッセージは、クラスターにコントロールプレーンノードが多すぎることを示しています。
status:
clusterHealth: green
conditions:
- lastTransitionTime: '2019-04-17T20:12:34Z'
message: >-
Invalid master nodes count. Please ensure there are no more than 3 total
nodes with master roles
reason: Invalid Settings
status: 'True'
type: InvalidMasters以下のステータスメッセージは、加えようとした変更が Elasticsearch ストレージでサポートされないことを示します。
以下に例を示します。
status:
clusterHealth: green
conditions:
- lastTransitionTime: "2021-05-07T01:05:13Z"
message: Changing the storage structure for a custom resource is not supported
reason: StorageStructureChangeIgnored
status: 'True'
type: StorageStructureChangeIgnored
reason および type フィールドは、サポート対象外の変更のタイプを指定します。
StorageClassNameChangeIgnored- ストレージクラス名の変更がサポートされていません。
StorageSizeChangeIgnored- ストレージサイズの変更がサポートされていません。
StorageStructureChangeIgnored一時ストレージと永続ストレージ構造間での変更がサポートされていません。
重要ClusterLoggingカスタムリソース (CR) を一時ストレージから永続ストレージに切り替えるように設定する場合に、OpenShift Elasticsearch Operator は永続ボリューム要求 (PVC) を作成しますが、永続ボリューム (PV) は作成されません。StorageStructureChangeIgnoredステータスを削除するには、ClusterLoggingCR への変更を元に戻し、PVC を削除する必要があります。
3.2.13.2.2. ログストアコンポーネントのステータスの表示
数多くのログストアコンポーネントのステータスを表示できます。
- Elasticsearch インデックス
Elasticsearch インデックスのステータスを表示できます。
Elasticsearch Pod の名前を取得します。
$ oc get pods --selector component=elasticsearch -o name
出力例
pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
インデックスのステータスを取得します。
$ oc exec elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -- indices
出力例
Defaulting container name to elasticsearch. Use 'oc describe pod/elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -n openshift-logging' to see all of the containers in this pod. green open infra-000002 S4QANnf1QP6NgCegfnrnbQ 3 1 119926 0 157 78 green open audit-000001 8_EQx77iQCSTzFOXtxRqFw 3 1 0 0 0 0 green open .security iDjscH7aSUGhIdq0LheLBQ 1 1 5 0 0 0 green open .kibana_-377444158_kubeadmin yBywZ9GfSrKebz5gWBZbjw 3 1 1 0 0 0 green open infra-000001 z6Dpe__ORgiopEpW6Yl44A 3 1 871000 0 874 436 green open app-000001 hIrazQCeSISewG3c2VIvsQ 3 1 2453 0 3 1 green open .kibana_1 JCitcBMSQxKOvIq6iQW6wg 1 1 0 0 0 0 green open .kibana_-1595131456_user1 gIYFIEGRRe-ka0W3okS-mQ 3 1 1 0 0 0
- ログストア Pod
ログストアをホストする Pod のステータスを表示できます。
Pod の名前を取得します。
$ oc get pods --selector component=elasticsearch -o name
出力例
pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
Pod のステータスを取得します。
$ oc describe pod elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
出力には、以下のようなステータス情報が含まれます。
出力例
.... Status: Running .... Containers: elasticsearch: Container ID: cri-o://b7d44e0a9ea486e27f47763f5bb4c39dfd2 State: Running Started: Mon, 08 Jun 2020 10:17:56 -0400 Ready: True Restart Count: 0 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... proxy: Container ID: cri-o://3f77032abaddbb1652c116278652908dc01860320b8a4e741d06894b2f8f9aa1 State: Running Started: Mon, 08 Jun 2020 10:18:38 -0400 Ready: True Restart Count: 0 .... Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True .... Events: <none>
- ログストレージ Pod デプロイメント設定
ログストアのデプロイメント設定のステータスを表示できます。
デプロイメント設定の名前を取得します。
$ oc get deployment --selector component=elasticsearch -o name
出力例
deployment.extensions/elasticsearch-cdm-1gon-1 deployment.extensions/elasticsearch-cdm-1gon-2 deployment.extensions/elasticsearch-cdm-1gon-3
デプロイメント設定のステータスを取得します。
$ oc describe deployment elasticsearch-cdm-1gon-1
出力には、以下のようなステータス情報が含まれます。
出力例
.... Containers: elasticsearch: Image: registry.redhat.io/openshift-logging/elasticsearch6-rhel8 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... Conditions: Type Status Reason ---- ------ ------ Progressing Unknown DeploymentPaused Available True MinimumReplicasAvailable .... Events: <none>
- ログストアのレプリカセット
ログストアのレプリカセットのステータスを表示できます。
レプリカセットの名前を取得します。
$ oc get replicaSet --selector component=elasticsearch -o name replicaset.extensions/elasticsearch-cdm-1gon-1-6f8495 replicaset.extensions/elasticsearch-cdm-1gon-2-5769cf replicaset.extensions/elasticsearch-cdm-1gon-3-f66f7d
レプリカセットのステータスを取得します。
$ oc describe replicaSet elasticsearch-cdm-1gon-1-6f8495
出力には、以下のようなステータス情報が含まれます。
出力例
.... Containers: elasticsearch: Image: registry.redhat.io/openshift-logging/elasticsearch6-rhel8@sha256:4265742c7cdd85359140e2d7d703e4311b6497eec7676957f455d6908e7b1c25 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... Events: <none>
3.2.13.2.3. Elasticsearch クラスターのステータス
OpenShift Container Platform Web コンソールのObserveセクションにあるダッシュボードには、Elasticsearch クラスターのステータスが表示されます。
OpenShift Elasticsearch クラスターのステータスを取得するには、OpenShift Container Platform Web コンソールのObserveセクションにあるダッシュボード <cluster_url>/monitoring/dashboards/grafana-dashboard-cluster-logging にアクセスします。
Elasticsearch ステータスフィールド
eo_elasticsearch_cr_cluster_management_stateElasticsearch クラスターが管理対象か、管理対象外かをを示します。以下に例を示します。
eo_elasticsearch_cr_cluster_management_state{state="managed"} 1 eo_elasticsearch_cr_cluster_management_state{state="unmanaged"} 0eo_elasticsearch_cr_restart_totalElasticsearch ノードが証明書の再起動、ローリング再起動、またはスケジュールされた再起動など、再起動した回数を示します。以下に例を示します。
eo_elasticsearch_cr_restart_total{reason="cert_restart"} 1 eo_elasticsearch_cr_restart_total{reason="rolling_restart"} 1 eo_elasticsearch_cr_restart_total{reason="scheduled_restart"} 3es_index_namespaces_totalElasticsearch インデックス namespace の総数を表示します。以下に例を示します。
Total number of Namespaces. es_index_namespaces_total 5
es_index_document_count各 namespace のレコード数を表示します。以下に例を示します。
es_index_document_count{namespace="namespace_1"} 25 es_index_document_count{namespace="namespace_2"} 10 es_index_document_count{namespace="namespace_3"} 5
Secret Elasticsearch フィールドが見つからないか、空というメッセージ
Elasticsearch に admin-cert、admin-key、logging-es.crt、または logging-es.key ファイルがない場合、ダッシュボードには次の例のようなステータスメッセージが表示されます。
message": "Secret \"elasticsearch\" fields are either missing or empty: [admin-cert, admin-key, logging-es.crt, logging-es.key]", "reason": "Missing Required Secrets",
3.2.13.3. ロギングサブシステムアラートについて
ロギングコレクターのアラートはすべて、OpenShift Container Platform Web コンソールの Alerting UI に一覧表示されます。
3.2.13.3.1. ロギングコレクターアラートの表示
アラートは、OpenShift Container Platform Web コンソールの、Alerting UI の Alerts タブに表示されます。アラートは以下の状態のいずれかになります。
- Firingアラートの状態はタイムアウトの期間は true になります。Firing アラートの末尾の Option メニューをクリックし、詳細情報を表示するか、アラートを非通知 (silence) にします。
- Pending: このアラート状態は現時点で true ですが、タイムアウトに達していません。
- Not Firingアラートは現時点でトリガーされていません。
手順
ロギングサブシステムおよびその他の OpenShift Container Platform アラートを表示するには:
- OpenShift Container Platform コンソールで Observe → Alerting の順にクリックします。
- Alerts タブをクリックします。選択したフィルターに基づいてアラートが一覧表示されます。
関連情報
- Alerting UI の詳細は、Managing alerts を参照してください。
3.2.13.3.2. ロギングコレクターのアラートについて
以下のアラートはロギングコレクターによって生成されます。これらのアラートは、OpenShift Container Platform Web コンソールの Alerting UI の Alerts ページで表示できます。
表3.18 Fluentd Prometheus アラート
| アラート | メッセージ | 説明 | 重大度 |
|---|---|---|---|
|
|
| FluentD 出力エラーの数は、デフォルトでは直前の 15 分間で 10 分を超えます。 | Warning |
|
|
| Fluentd は Prometheus が特定の Fluentd インスタンスを収集できなかったことを報告します。 | Critical |
|
|
| Fluentd はキューサイズが増加していることを報告しています。 | Critical |
|
|
| FluentD 出力エラーの数は非常に高くなります。デフォルトでは、直前の 15 分間で 25 を超えます。 | Critical |
3.2.13.3.3. Elasticsearch アラートルール
これらのアラートルールを Prometheus に表示できます。
表3.19 アラートルール
| アラート | 説明 | 重大度 |
|---|---|---|
|
| クラスターのヘルスステータスは少なくとも 2m の間 RED になります。クラスターは書き込みを受け入れず、シャードが見つからない可能性があるか、マスターノードがまだ選択されていません。 | Critical |
|
| クラスターのヘルスステータスは少なくとも 20m の間 YELLOW になります。一部のシャードレプリカは割り当てられません。 | Warning |
|
| クラスターでは、次の 6 時間以内にディスク領域が不足することが予想されます。 | Critical |
|
| クラスターでは、次の 1 時間以内にファイル記述子が不足することが予想されます。 | Warning |
|
| 指定されたノードでの JVM ヒープの使用率が高くなっています。 | アラート |
|
| 指定されたノードは、ディスクの空き容量が少ないために低基準値に達しています。シャードをこのノードに割り当てることはできません。ノードにディスク領域を追加することを検討する必要があります。 | Info |
|
| 指定されたノードは、ディスクの空き容量が少ないために高基準値に達しています。一部のシャードは可能な場合に別のノードに再度割り当てられる可能性があります。ノードにディスク領域が追加されるか、このノードに割り当てられる古いインデックスをドロップします。 | Warning |
|
| 指定されたノードは、ディスクの空き容量が少ないために高基準値に達しています。このノードにシャードが割り当てられるすべてのインデックスは、読み取り専用ブロックになります。インデックスブロックは、ディスクの使用状況が高基準値を下回る場合に手動で解放される必要があります。 | Critical |
|
| 指定されたノードの JVM ヒープの使用率が高すぎます。 | アラート |
|
| Elasticsearch では、指定されたノードで書き込み拒否が増加しています。このノードはインデックスの速度に追い付いていない可能性があります。 | Warning |
|
| 指定されたノードのシステムで使用される CPU が高すぎます。 | アラート |
|
| 指定されたノードで Elasticsearch によって使用される CPU が高すぎます。 | アラート |
3.2.13.4. Red Hat サポート用のロギングデータの収集
サポートケースを作成する際、ご使用のクラスターのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。
must-gather ツール を使用すると、プロジェクトレベルのリソース、クラスターレベルのリソース、および各ロギングシステムコンポーネントについての診断情報を収集できます。
迅速なサポートを得るには、OpenShift Container Platform と OpenShift Logging の両方の診断情報を提供してください。
hack/logging-dump.sh スクリプトは使用しないでください。このスクリプトはサポートされなくなり、データを収集しません。
3.2.13.4.1. must-gather ツールについて
oc adm must-gather CLI コマンドは、問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。
ロギングサブシステムの場合、must-gather は次の情報を収集します。
- プロジェクトレベルの Pod、設定マップ、サービスアカウント、ロール、ロールバインディングおよびイベントを含むプロジェクトレベルのリソース
- クラスターレベルでのノード、ロール、およびロールバインディングを含むクラスターレベルのリソース
-
ログコレクター、ログストア、およびログビジュアライザーなどの
openshift-loggingおよびopenshift-operators-redhatnamespace の OpenShift Logging リソース
oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。
3.2.13.4.2. 前提条件
- ロギングサブシステムと Elasticsearch をインストールする必要があります。
3.2.13.4.3. OpenShift Logging データの収集
oc adm must-gather CLI コマンドを使用して、ロギングサブシステムに関する情報を収集できます。
手順
must-gather でロギングサブシステム情報を収集するには、以下を実行します。
-
must-gather情報を保存する必要のあるディレクトリーに移動します。 OpenShift Logging イメージに対して
oc adm must-gatherコマンドを実行します。$ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')must-gatherツールは、現行ディレクトリー内のmust-gather.localで始まる新規ディレクトリーを作成します。例:must-gather.local.4157245944708210408作成された
must-gatherディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。$ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
- 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。
3.2.13.5. Critical Alerts のトラブルシューティング
3.2.13.5.1. Elasticsearch クラスターの正常性が赤である
1 つ以上のプライマリーシャードとそのレプリカがノードに割り当てられません。
トラブルシューティング
Elasticsearch クラスターの正常性を確認し、クラスターの
ステータスが赤であることを確認します。oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health
クラスターにに参加したノードを一覧表示します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/nodes?v
Elasticsearch Pod を一覧表示し、この Pod を直前の手順のコマンド出力にあるノードと比較します。
oc -n openshift-logging get pods -l component=elasticsearch
一部の Elasticsearch ノードがクラスターに参加していない場合は、以下の手順を実行します。
Elasticsearch に選ばれたコントロールプレーンノードがあることを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/master?v
選ばれたコントロールプレーンノードの Pod ログで問題を確認します。
oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging
問題がないか、クラスターに参加していないノードのログを確認します。
oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging
全ノードがクラスターに参加している場合は、以下の手順を実行し、クラスターがリカバリープロセスにあるかどうかを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/recovery?active_only=true
コマンドの出力がない場合は、リカバリープロセスが保留中のタスクによって遅延しているか、停止している可能性があります。
保留中のタスクがあるかどうかを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health |grep number_of_pending_tasks
保留中のタスクがある場合は、そのステータスを監視します。
そのステータスが変化し、クラスターがリカバリー中の場合は、そのまま待機します。リカバリー時間は、クラスターのサイズや他の要素により異なります。
保留中のタスクのステータスが変更されない場合は、リカバリーが停止していることがわかります。
リカバリーが停止しているようであれば、
cluster.routing.allocation.enableがnoneに設定されているかどうかを確認します。oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty
cluster.routing.allocation.enableがnoneに設定されている場合は、これをallに設定します。oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty -X PUT -d '{"persistent": {"cluster.routing.allocation.enable":"all"}}'どのインデックスが赤のままかを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v
インデックスがまだ赤い場合は、以下の手順を実行して赤のインデックスをなくします。
キャッシュをクリアします。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty
最大割り当ての再試行回数を増やします。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.allocation.max_retries":10}'スクロールアイテムをすべて削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_search/scroll/_all -X DELETE
タイムアウトを増やします。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.unassigned.node_left.delayed_timeout":"10m"}'
前述の手順で赤色のインデックスがなくならない場合は、インデックスを個別に削除します。
赤色のインデックスの名前を特定します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v
赤色のインデックスを削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_red_index_name> -X DELETE
赤色のインデックスがなく、クラスターのステータスが赤の場合は、データノードで継続的に過剰な処理負荷がかかっていないかを確認します。
Elasticsearch JVM ヒープの使用量が多いかどうかを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_nodes/stats?pretty
コマンド出力で
node_name.jvm.mem.heap_used_percentフィールドを確認し、JVM ヒープ使用量を判別します。- 使用量が多い CPU がないかを確認します。
関連情報
- Elasticsearch で "Free up or increase disk space" と検索し、クラスターのステータスが赤または黄色の問題を修正します。
3.2.13.5.2. Elasticsearch クラスターの正常性が黄色である
1 つ以上のプライマリーシャードのレプリカシャードがノードに割り当てられません。
トラブルシューティング
-
ClusterLoggingCR でnodeCountを調整してノード数を増やします。
関連情報
- クラスターロギングカスタムリソースについて
- ログストアの永続ストレージの設定
- Elasticsearch で "Free up or increase disk space" と検索し、クラスターのステータスが赤または黄色の問題を修正します。
3.2.13.5.3. Elasticsearch Node Disk Low Watermark Reached (Elasticsearch ノードのディスクで低い基準値に達する)
Elasticsearch で、低基準値に到達した ノードにシャードが割り当てられません。
トラブルシューティング
Elasticsearch のデプロイ先のノードを特定します。
oc -n openshift-logging get po -o wide
未割り当てのシャードがあるかどうかを確認します。oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep unassigned_shards
未割り当てのシャードがある場合は、各ノードのディスク領域を確認します。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; donenodes.node_name.fsフィールドで、対象のノードの空きディスク領域を確認します。使用済みディスクの割合が 85% を超える場合は、ノードは低基準値を超えており、シャードがこのノードに割り当てられなくなります。
- すべてのノードでディスク領域を増やしてみてください。
- ディスク領域を増やせない場合は、新しいデータノードをクラスターに追加してみてください。
新規データノードの追加に問題がある場合は、クラスターの冗長性ポリシー総数を減らします。
現在の
redundancyPolicyを確認します。oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'注記ClusterLoggingCR を使用している場合は、以下を入力します。oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'-
クラスター
redundancyPolicyがSingleRedundancyよりも大きい場合は、SingleRedundancyに設定し、この変更を保存します。
前述の手順で問題が解決しない場合は、古いインデックスを削除します。
Elasticsearch の全インデックスのステータスを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
- 古いインデックスで削除できるものを特定します。
インデックスを削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
関連情報
-
About the Cluster Logging custom resource の
ClusterLoggingカスタムリソース (CR) のサンプルで redundancyPolicy を参照します。
3.2.13.5.4. Elasticsearch Node Disk High Watermark Reached (Elasticsearch ノードのディスクで高い基準値に達する)
Elasticsearch が 高基準値に達した ノードからシャードを移動しようとします。
トラブルシューティング
Elasticsearch のデプロイ先のノードを特定します。
oc -n openshift-logging get po -o wide
各ノードのディスク容量を確認します。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; doneクラスターがリバランスされているかどうかを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep relocating_shards
コマンドの出力でシャードの再配置が表示される場合は、高い基準値を超過しています。高い基準値のデフォルト値は 90% です。
基準値のしきい値上限を超えておらず、ディスクの使用量が少ないノードに、シャードを移動します。
- シャードを特定ノードに割り当てるには、領域の一部を解放します。
- すべてのノードでディスク領域を増やしてみてください。
- ディスク領域を増やせない場合は、新しいデータノードをクラスターに追加してみてください。
新規データノードの追加に問題がある場合は、クラスターの冗長性ポリシー総数を減らします。
現在の
redundancyPolicyを確認します。oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'注記ClusterLoggingCR を使用している場合は、以下を入力します。oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'-
クラスター
redundancyPolicyがSingleRedundancyよりも大きい場合は、SingleRedundancyに設定し、この変更を保存します。
前述の手順で問題が解決しない場合は、古いインデックスを削除します。
Elasticsearch の全インデックスのステータスを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
- 古いインデックスで削除できるものを特定します。
インデックスを削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
関連情報
-
About the Cluster Logging custom resource の
ClusterLoggingカスタムリソース (CR) のサンプルで redundancyPolicy を参照します。
3.2.13.5.5. Elasticsearch Node Disk Flood Watermark Reached (Elasticsearch ノードのディスクがいっぱいの基準値に達する)
Elasticsearch は、両条件が含まれるすべてのインデックスに対して読み取り専用のインデックスブロックを強制的に適用します。
- 1 つ以上のシャードがノードに割り当てられます。
- 1 つ以上のディスクが いっぱいの段階 を超えています。
トラブルシューティング
Elasticsearch ノードのディスク領域を確認します。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; donenodes.node_name.fsフィールドで、対象のノードの空きディスク領域を確認します。- 使用済みディスクの割合が 95% を超える場合は、ノードがいっぱいの基準値が越えたことを意味します。この特定のノードに割り当てられたシャードへの書き込みは、ブロックされます。
- すべてのノードでディスク領域を増やしてみてください。
- ディスク領域を増やせない場合は、新しいデータノードをクラスターに追加してみてください。
新規データノードの追加に問題がある場合は、クラスターの冗長性ポリシー総数を減らします。
現在の
redundancyPolicyを確認します。oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'注記ClusterLoggingCR を使用している場合は、以下を入力します。oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'-
クラスター
redundancyPolicyがSingleRedundancyよりも大きい場合は、SingleRedundancyに設定し、この変更を保存します。
前述の手順で問題が解決しない場合は、古いインデックスを削除します。
Elasticsearch の全インデックスのステータスを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
- 古いインデックスで削除できるものを特定します。
インデックスを削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
ディスク使用領域が 90% 未満になるまで、このままディスク領域を解放して監視します。次に、この特定のノードへの書き込み禁止を解除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_all/_settings?pretty -X PUT -d '{"index.blocks.read_only_allow_delete": null}'
関連情報
-
About the Cluster Logging custom resource の
ClusterLoggingカスタムリソース (CR) のサンプルで redundancyPolicy を参照します。
3.2.13.5.6. Elasticsearch JVM ヒープの使用量が高い
Elasticsearch ノードで使用済みの JVM ヒープメモリーが 75% を超えます。
トラブルシューティング
ヒープサイズを増やす ことを検討してください。
3.2.13.5.7. 集計ロギングシステムの CPU が高い
ノード上のシステムの CPU 使用量が高くなります。
トラブルシューティング
クラスターノードの CPU を確認します。ノードへ割り当てる CPU リソースを増やすことを検討してください。
3.2.13.5.8. Elasticsearch プロセスの CPU が高い
ノードでの Elasticsearch プロセスの CPU 使用量が高くなります。
トラブルシューティング
クラスターノードの CPU を確認します。ノードへ割り当てる CPU リソースを増やすことを検討してください。
3.2.13.5.9. Elasticsearch ディスク領域が不足している
Elasticsearch クラスターは、現在のディスク使用量に基づいて次の 6 時間以内にディスク領域が不足することが予想します。
トラブルシューティング
Elasticsearch ノードのディスク領域を取得します。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done-
コマンド出力の
nodes.node_name.fsフィールドで、対象ノードの空きディスク領域を確認します。 - すべてのノードでディスク領域を増やしてみてください。
- ディスク領域を増やせない場合は、新しいデータノードをクラスターに追加してみてください。
新規データノードの追加に問題がある場合は、クラスターの冗長性ポリシー総数を減らします。
現在の
redundancyPolicyを確認します。oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'注記ClusterLoggingCR を使用している場合は、以下を入力します。oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'-
クラスター
redundancyPolicyがSingleRedundancyよりも大きい場合は、SingleRedundancyに設定し、この変更を保存します。
前述の手順で問題が解決しない場合は、古いインデックスを削除します。
Elasticsearch の全インデックスのステータスを確認します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
- 古いインデックスで削除できるものを特定します。
インデックスを削除します。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
関連情報
-
About the Cluster Logging custom resource の
ClusterLoggingカスタムリソース (CR) のサンプルで redundancyPolicy を参照します。 - About Elasticsearch alerting rules で ElasticsearchDiskSpaceRunningLow を参照します。
- Elasticsearch で "Free up or increase disk space" と検索し、クラスターのステータスが赤または黄色の問題を修正します。
3.2.13.5.10. Elasticsearch FileDescriptor の使用量が高い
現在の使用傾向に基づいて、ノードで予測されるファイル記述子の数は十分ではありません。
トラブルシューティング
必要に応じて、Elasticsearch ファイル記述子 のトピックで説明されているように、各ノードの max_file_descriptors の値を確認して設定します。
関連情報
- About Elasticsearch alerting rules で ElasticsearchHighFileDescriptorUsage を参照します。
- OpenShift Logging dashboards で File Descriptors In Use を参照します。
3.2.14. OpenShift Logging のアンインストール
OpenShift Container Platform クラスターからロギングサブシステムを削除できます。
3.2.14.1. Red Hat のロギングサブシステムのアンインストール
ClusterLogging カスタムリソース (CR) を削除して、ログ集計を停止できます。CR を削除した後、残っている他のロギングサブシステムコンポーネントがあり、オプションで削除できます。
ClusterLogging CR を削除しても、永続ボリューム要求 (PVC) は削除されません。残りの PVC、永続ボリューム (PV)、および関連データを保持するか、削除するには、さらにアクションを実行する必要があります。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
OpenShift Logging を削除するには、以下を実行します。
OpenShift Container Platform Web コンソールを使用して
ClusterLoggingCR を削除できます。- Administration → Custom Resource Definitions ページに切り替えます。
- Custom Resource Definitions ページで、ClusterLogging をクリックします。
- Custom Resource Definition Details ページで、 Instances をクリックします。
-
インスタンスの横にある Options メニュー
をクリックし、Delete ClusterLogging を選択します。
オプション: カスタムリソース定義 (CRD) を削除します。
- Administration → Custom Resource Definitions ページに切り替えます。
-
ClusterLogForwarder の横にある Options メニュー
をクリックし、Delete Custom Resource Definition を選択します。
-
ClusterLogging の横にある Options メニュー
をクリックし、Delete Custom Resource Definition を選択します。
-
Elasticsearch の横にある Options メニュー
をクリックし、Delete Custom Resource Definition を選択します。
オプション: Red Hat OpenShift Logging Operator および OpenShift Elasticsearch Operator を削除します。
- Operators → Installed Operators ページに切り替えます。
-
Red Hat OpenShift Logging Operator の横にある Options メニュー
をクリックし、Uninstall Operator を選択します。
-
OpenShift Elasticsearch Operator の横にある Options メニュー
をクリックし、Uninstall Operator を選択します。
オプション: Cluster Logging および Elasticsearch プロジェクトを削除します。
- Home → Projects ページに切り替えます。
-
openshift-logging プロジェクトの横にある Options メニュー
をクリックし、Delete Project を選択します。
-
ダイアログボックスで
openshift-loggingを入力して、Delete をクリックし、削除を確認します。 openshift-operators-redhat プロジェクトの横にある Options メニュー
をクリックし、Delete Project を選択します。
重要他のグローバル Operator がこの namespace にインストールされている場合は、
openshift-operators-redhatプロジェクトを削除しないでください。-
ダイアログボックスで
openshift-operators-redhatを入力し、Delete をクリックして削除を確認します。
- 他の Pod で再利用するために PVC を保持するには、PVC の回収に必要なラベルまたは PVC 名を保持します。
オプション: PVC を保持する必要がない場合は、それを削除できます。
警告PVC の解放または削除により PV が削除され、データの損失が生じる可能性があります。
- Storage → Persistent Volume Claims ページに切り替えます。
-
各 PVC の横にある Options メニュー
をクリックし、Delete Persistent Volume Claim を選択します。
- ストレージ領域を回復する必要がある場合は、PV を削除できます。
関連情報
3.2.15. ログレコードのフィールド
次のフィールドは、ロギングサブシステムによってエクスポートされたログレコードに存在する可能性があります。ログレコードは通常 JSON オブジェクトとしてフォーマットされますが、同じデータモデルは他のエンコーディングに適用できます。
Elasticsearch および Kibana からこれらのフィールドを検索するには、検索時に点線の全フィールド名を使用します。たとえば、Elasticsearch /_search URL の場合、Kubernetes Pod 名を検索するには、/_search/q=kubernetes.pod_name:name-of-my-pod を使用します。
最上位フィールドはすべてのレコードに存在する可能性があります。