第1章 クラスターロギングおよび OpenShift Dedicated について

管理者は、クラスターロギングをデプロイし、さまざまな OpenShift Dedicated サービスのログを集計できます。

クラスターロギングはワーカーノードで実行されます。管理者は、コンソールおよび Prometheus および Grafana でリソースの消費を監視できます。ロギングには高い負荷が必要となるため、さらに多くのワーカーノードが環境になる可能性があります。

OpenShift Dedicated のログは、ローテーションの前の 2 日間保持されます。ロギングストレージの上限は 600GiB に設定されます。これは、クラスターの割り当て済みのベースストレージとは別個に設定されます。

1.1. クラスターロギング

OpenShift Dedicated 管理者は、OperatorHub 経由でクラスターロギングおよび Elasticsearch Operator をデプロイでき、ロギングを openshift-logging namespace に設定できます。ロギングを設定すると、Elasticsearch、Fluentd、および Kibana が openshift-logging namespace にデプロイされます。Operator はクラスターロギングのデプロイ、アップグレード、およびメンテナンスを行います。

クラスターロギングは、instance という名前のクラスターロギングのカスタムリソース (CR) を変更することで設定できます。CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なクラスターロギングデプロイメントを定義します。Cluster Logging Operator は ClusterLogging カスタムリソースを監視し、ロギングデプロイメントを適宜調整します。

管理者およびアプリケーション開発者は、表示アクセスを持つプロジェクトのログを表示できます。

1.1.1. クラスターロギングコンポーネント

クラスターロギングコンポーネントは Elasticsearch、Fluentd、Kibana (EFK) に基づいています。コレクターの Fluentd は、OpenShift Dedicated クラスターの各ノードにデプロイされます。これはすべてのノードおよびコンテナーのログを収集し、それらを Elasticsearch (ES) に書き込みます。Kibana は、ユーザーおよび管理者が集計されたデータを使って高度な視覚化およびダッシュボードを作成できる中央の Web UI です。

現時点で、5 種類のクラスターロギングコンポーネントがあります。

  • logStore: これはログが保存される場所です。現在の実装は Elasticsearch です。
  • collection: これは、ノードからログを収集し、それらをフォーマットし、logStore に保存するコンポーネントです。現在の実装は Fluentd です。
  • visualization: これは、ログ、グラフ、チャートなどを表示するために使用される UI コンポーネントです。現在の実装は Kibana です。
  • curation: これは期間に基づいてログをトリミングするコンポーネントです。現在の実装は Curator です。
  • event routing: これは、OpenShift Dedicated イベントをクラスターロギングに転送するコンポーネントです。現在の実装はイベントルーターです。

本書では、特筆されない限り、logStore と Elasticsearch、visualization と Kibana、curation と Curator、collection と Fluentd を区別せずに使用する場合があります。

1.1.2. logStore について

OpenShift Dedicated は Elasticsearch (ES) を使用して Fluentd からのログデータを、データストアまたはインデックスに編成します。

Elasticsearch は、各インデックスを シャード と呼ばれる複数の部分に細分化し、Elasticsearch クラスター内の Elasticsearch ノードセット全体に分散します。Elasticsearch を レプリカ というシャードのコピーを作成するように設定できます。さらに、Elasticsearch はレプリカを Elactisearch ノード全体に分散します。ClusterLogging カスタムリソースにより、カスタムリソース定義 (CRD) にレプリケーションポリシーを指定して、データの冗長性および耐障害性を提供することができます。

注記

インデックステンプレートのプライマリーシャードの数は 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 Dedicated は Fluentd を使用してクラスターについてのデータを収集します。

ロギングコレクターは、Pod を各 OpenShift Dedicated ノードにデプロイする OpenShift Dedicated の daemonsetとしてデプロイされます。journald は、オペレーティングシステム、コンテナーランタイム、および OpenShift Dedicated からのログメッセージを提供するシステムログソースです。

コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合、ラベルやアノテーションなどの API サーバーからの情報は利用できない可能性があります。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡することができない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。

重要

利用可能なコンテナーランタイムは、ログメッセージのソースを特定するための最小限の情報を提供し、個別のログメッセージが一意となる確証はなく、これらのメッセージにより、そのソースを追跡できる訳ではありません。

詳細情報は、「 Fluentd」を参照してください。

1.1.4. ロギングの視覚化について

OpenShift Dedicated は 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
1
Curator スケジュールを cron 形式 で指定します。

詳細は「Curator」を参照してください。

1.1.6. イベントルーターについて

イベントルーターは、OpenShift Dedicated イベントをクラスターロギングに転送する Pod です。イベントルーターは手動でデプロイする必要があります。

イベントルーターはイベントを収集し、それらを JSON 形式に変換します。この形式では、イベントの取得後、それらを STDOUT にプッシュします。Fluentd はイベントを .operations インデックスにインデックス化します。

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
      storage:
        storageClassName: "gp2"
        size: "200Gi"
      redundancyPolicy: "SingleRedundancy"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      resources:
        request:
          memory: 8G
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
      nodeSelector:
        node-role.kubernetes.io/worker: ""
  curation:
    type: "curator"
    curator:
      schedule: "30 3 * * *"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
  collection:
    logs:
      type: "fluentd"
      fluentd: {}
      nodeSelector:
        node-role.kubernetes.io/worker: ""