9.3. OpenShift Serverless を使用したクラスターロギング
9.3.1. クラスターロギング
OpenShift Container Platform クラスター管理者は、いくつかの CLI コマンドを使用してクラスターロギングをデプロイでき、OpenShift Container Platform Web コンソールを使用して Elasticsearch Operator および Cluster Logging Operator をインストールできます。Operator がインストールされている場合、クラスターロギングのカスタムリソース (Custom Resource、CR) を作成してクラスターロギング Pod およびクラスターロギングのサポートに必要な他のリソースをスケジュールします。Operator はクラスターロギングのデプロイ、アップグレード、および維持を行います。
クラスターロギングは、instance
という名前のクラスターロギングのカスタムリソース (CR) を変更することで設定できます。CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なクラスターロギングデプロイメントを定義します。Cluster Logging Operator は ClusterLogging
カスタムリソースを監視し、ロギングデプロイメントを適宜調整します。
管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。
9.3.2. クラスターロギングのデプロイおよび設定について
OpenShift Container Platform クラスターロギングは、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。
以下のインストール方法には、サンプルのクラスターロギングのカスタムリソース (CR) が含まれます。これを使用して、クラスターロギングインスタンスを作成し、クラスターロギングのデプロイメントを設定することができます。
デフォルトのクラスターロギングインストールを使用する必要がある場合は、サンプル CR を直接使用できます。
デプロイメントをカスタマイズする必要がある場合、必要に応じてサンプル CR に変更を加えます。以下では、クラスターロギングのインスタンスをインストール時に実行し、インストール後に変更する設定について説明します。クラスターロギングのカスタムリソース外で加える変更を含む、各コンポーネントの使用方法については、設定についてのセクションを参照してください。
9.3.2.1. クラスターロギングの設定およびチューニング
クラスターロギング環境は、openshift-logging
プロジェクトにデプロイされるクラスターロギングのカスタムリソースを変更することによって設定できます。
インストール時またはインストール後に、以下のコンポーネントのいずれかを変更することができます。
- メモリーおよび CPU
-
resources
ブロックを有効なメモリーおよび CPU 値で変更することにより、各コンポーネントの CPU およびメモリーの両方の制限を調整することができます。
spec: logStore: elasticsearch: resources: limits: cpu: memory: 16Gi requests: cpu: 500m memory: 16Gi type: "elasticsearch" collection: logs: fluentd: resources: limits: cpu: memory: requests: cpu: memory: type: "fluentd" visualization: kibana: resources: limits: cpu: memory: requests: cpu: memory: type: kibana curation: curator: resources: limits: memory: 200Mi requests: cpu: 200m memory: 200Mi type: "curator"
- Elasticsearch ストレージ
-
storageClass
name
およびsize
パラメーターを使用し、Elasticsearch クラスターの永続ストレージのクラスおよびサイズを設定できます。Cluster Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについてPersistentVolumeClaim
を作成します。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
この例では、クラスターの各データノードが「gp2」ストレージの「200G」を要求する PersistentVolumeClaim
にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。
storage
ブロックを省略すると、一時ストレージのみを含むデプロイメントになります。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
- Elasticsearch レプリケーションポリシー
Elasticsearch シャードをクラスター内のデータノードにレプリケートする方法を定義するポリシーを設定できます。
-
FullRedundancy
:各インデックスのシャードはすべてのデータノードに完全にレプリケートされます。 -
MultipleRedundancy
:各インデックスのシャードはデータノードの半分に分散します。 -
SingleRedundancy
:各シャードの単一コピー。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。 -
ZeroRedundancy
:シャードのコピーはありません。ログは、ノードの停止または失敗時に利用不可になる (または失われる) 可能性があります。
-
- Curator スケジュール
- Curator のスケジュールを cron 形式で指定します。
spec: curation: type: "curator" resources: curator: schedule: "30 3 * * *"
9.3.2.2. 変更されたクラスターロギングカスタムリソースのサンプル
以下は、前述のオプションを使用して変更されたクラスターロギングのカスタムリソースの例です。
変更されたクラスターロギングカスタムリソースのサンプル
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: limits: memory: 32Gi requests: cpu: 3 memory: 32Gi storage: {} redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: limits: memory: 1Gi requests: cpu: 500m memory: 1Gi replicas: 1 curation: type: "curator" curator: resources: limits: memory: 200Mi requests: cpu: 200m memory: 200Mi schedule: "*/5 * * * *" collection: logs: type: "fluentd" fluentd: resources: limits: memory: 1Gi requests: cpu: 200m memory: 1Gi
9.3.3. クラスターロギングの使用による Knative Serving コンポーネントのログの検索
手順
Kibana ルートを取得します。
$ oc -n openshift-logging get route kibana
- ルートの URL を使用して Kibana ダッシュボードに移動し、ログインします。
- インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
knative-serving
namespace を使用してログをフィルターできます。kubernetes.namespace_name:knative-serving
を検索ボックスに入力して結果をフィルターします。注記Knative Serving はデフォルトで構造化ロギングを使用します。クラスターロギング Fluentd 設定をカスタマイズしてこれらのログの解析を有効にできます。これにより、ログの検索がより容易になり、ログレベルでのフィルターにより問題を迅速に特定できるようになります。
9.3.4. クラスターロギングを使用した Knative Serving でデプロイされたサービスのログの検索
OpenShift クラスターロギングにより、アプリケーションがコンソールに書き込むログは Elasticsearch で収集されます。以下の手順で、Knative Serving を使用してデプロイされたアプリケーションにこれらの機能を適用する方法の概要を示します。
手順
Kibana URL を取得します。
$ oc -n cluster-logging get route kibana`
- URL をブラウザーに入力し、Kibana UI を開きます。
- インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
サービスがデプロイされている Kubernetes namespace を使用してログをフィルターします。フィルターを追加してサービス自体を特定します:
kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}
注記/configuration
または/revision
を使用してフィルターすることもできます。kubernetes.container_name:<user-container>
を使用して検索を絞り込み、ご使用のアプリケーションで生成されるログのみを表示することができます。それ以外の場合は、queue-proxy からのログが表示されます。注記アプリケーションで JSON ベースの構造化ロギングを使用することで、実稼働環境でのこれらのログの迅速なフィルターを実行できます。