第1章 クラスターロギングおよび OpenShift Container Platform について
クラスター管理者は、クラスターロギングをデプロイし、ノードシステムログ、アプリケーションコンテナーログなどの OpenShift Container Platform クラスターからのすべてのログを集計できます。
1.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
カスタムリソースを監視し、ロギングデプロイメントを適宜調整します。
管理者およびアプリケーション開発者は、表示アクセスを持つプロジェクトのログを表示できます。
1.1.1. クラスターロギングコンポーネント
クラスターロギングコンポーネントは Elasticsearch、Fluentd、Kibana (EFK) に基づいています。コレクターの Fluentd は、OpenShift Container Platform クラスターの各ノードにデプロイされます。これはすべてのノードおよびコンテナーのログを収集し、それらを Elasticsearch (ES) に書き込みます。Kibana は、ユーザーおよび管理者が集計されたデータを使って高度な視覚化およびダッシュボードを作成できる中央の Web UI です。
現時点で、5 種類のクラスターロギングコンポーネントがあります。
- logStore: これはログが保存される場所です。現在の実装は Elasticsearch です。
- collection: これは、ノードからログを収集し、それらをフォーマットし、logStore に保存するコンポーネントです。現在の実装は Fluentd です。
- visualization: これは、ログ、グラフ、チャートなどを表示するために使用される UI コンポーネントです。現在の実装は Kibana です。
- curation: これは期間に基づいてログをトリミングするコンポーネントです。現在の実装は Curator です。
本書では、特筆されない限り、logStore と Elasticsearch、visualization と Kibana、curation と Curator、collection と Fluentd を区別せずに使用する場合があります。
1.1.2. ログストアについて
OpenShift Container Platform は Elasticsearch (ES) を使用して Fluentd からのログデータを、データストアまたは インデックス に編成します。
Elasticsearch は、各インデックスを シャード と呼ばれる複数の部分に細分化し、Elasticsearch クラスター内の Elasticsearch ノードセット全体に分散します。Elasticsearch を レプリカ というシャードのコピーを作成するように設定できます。さらに、Elasticsearch はレプリカを Elactisearch ノード全体に分散します。ClusterLogging カスタムリソースにより、カスタムリソース定義 (Custom Resource Definition、CRD) にレプリケーションポリシーを指定して、データの冗長性および耐障害性を提供することができます。
クラスターロギング Elasticsearch インスタンスは、短期 (約 7 日間) の保存について最適化され、テストされています。長期間ログを保持する必要がある場合は、データをサードパーティーのストレージシステムに移動することが推奨されます。
インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。
Cluster Logging Operator および Elasticsearch Operator は、各 Elasticsearch ノードが独自のストレージボリュームを含む一意の Deployment を使用してデプロイされるようにします。クラスターロギングのカスタムリソース (CR) を使用して Elasticsearch ノードの数を増やすことができます。以下に示すように、ストレージおよびネットワークの場所を選択する際の留意事項については、Elastic のドキュメント を参照してください。
可用性の高い Elasticsearch 環境には 3 つ以上の Elasticsearch ノードが必要で、それぞれが別のホストに置かれる必要があります。
Elasticsearch インデックスに適用されているロールベースアクセス制御 (RBAC) は、開発者のログの制御アクセスを可能にします。project.{project_name}.{project_uuid}.*
形式を使用したインデックスへのアクセスは、特定プロジェクトのユーザーのパーミッションに基づいて制限されます。
詳細は「Elasticsearch (ES)」を参照してください。
1.1.3. ロギングコレクターについて
OpenShift Container Platform は Fluentd を使用してクラスターについてのデータを収集します。
ロギングコレクターは、Pod を各 OpenShift Container Platform ノードにデプロイする OpenShift Container Platform の daemonsetとしてデプロイされます。journald
は、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からのログメッセージを提供するシステムログソースです。
コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合、ラベルやアノテーションなどの API サーバーからの情報は利用できない可能性があります。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡することができない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。
利用可能なコンテナーランタイムは、ログメッセージのソースを特定するための最小限の情報を提供し、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、そのソースを追跡できる訳ではありません。
詳細情報は、「 Fluentd」を参照してください。
1.1.4. ロギングの視覚化について
OpenShift Container Platform は Kibana を使用して、Fluentd によって収集され、Elasticsearch によってインデックス化されるログデータを表示します。
Kibana は、ヒストグラム、線グラフ、円グラフ、ヒートマップ、ビルトインされた地理空間サポート、その他の視覚化機能を使用して Elasticsearch データをクエリーし、検出し、視覚化するためのブラウザーベースのコンソールインターフェースです。
詳細は、「Kibana」を参照してください。
1.1.5. ロギング curation について
Elasticsearch Curator ツールは、グローバルに、またはプロジェクトごとにスケジュールされたメンテナンス操作を実行します。Curator はその設定に基づいて動作を実行します。Elasticsearch クラスターあたり 1 つの Curator Pod のみの使用が推奨されます。
spec:
curation:
type: "curator"
resources:
curator:
schedule: "30 3 * * *" 1
詳細は「Curator」を参照してください。
1.1.6. イベントのルーティングについて
イベントルーターは、クラスターロギングで収集できるように OpenShift Container Platform イベントを監視する Pod です。イベントルーターはすべてのプロジェクトからイベントを収集し、それらを STDOUT
に書き込みます。Fluentd はそれらのイベントを収集し、それらを OpenShift Container Platform Elasticsearch インスタンスに転送します。Elasticsearch はイベントを infra
インデックスにインデックス化します。
イベントルーターは手動でデプロイする必要があります。
1.1.7. クラスターロギングカスタムリソースについて
クラスターロギングデプロイメントを変更するには、クラスターロギングカスタムリソース (CR) を作成し、変更します。CR の作成または変更方法については、このドキュメントで適宜説明されます。
以下は、クラスターロギングの通常のクラスターリソースの例です。
クラスターロギング CR の例
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: 16Gi requests: cpu: 500m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources: limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 curation: type: "curator" curator: resources: limits: memory: 200Mi requests: cpu: 200m memory: 200Mi schedule: "*/10 * * * *" collection: logs: type: "fluentd" fluentd: resources: limits: memory: 1Gi requests: cpu: 200m memory: 1Gi