ロギング

OpenShift Dedicated 4

OpenShift Dedicated 4 でのクラスターロギングの設定

Red Hat OpenShift Documentation Team

概要

本書では、クラスターロギング機能のインストール、設定および使用方法について説明します。クラスターロギングは、各種の OpenShift Dedicated サービスについてのログを集計します。

第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: ""

第2章 クラスターロギングおよび Elasticsearch Operator のインストール

2.1. クラスターロギングおよび Elasticsearch Operator のインストール

OpenShift Dedicated コンソールを使用し、クラスターロギングおよび Elasticsearch Operator のインスタンスをデプロイしてクラスターロギングをインストールできます。Cluster Logging Operator はロギングスタックのコンポーネントを作成し、管理します。Elasticsearch Operator は、クラスターロギングによって使用される Elasticsearch クラスターを作成し、管理します。

注記

OpenShift Dedicated クラスターロギングソリューションでは、Cluster Logging Operator と Elasticsearch Operator の両方をインストールする必要があります。Cluster Logging Operator のインスタンスをデプロイする場合、これは Elasticsearch Operator のインスタンスもデプロイします。

OpenShift Dedicated クラスターには、クラスターロギング用に Elasticsearch をデプロイするために排他的に使用できる 600 GiB の永続ストレージが含まれます。

Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、メモリー要求および制限の両方に 8G のメモリーが必要です。各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨されません。

手順

  1. OperatorHub から Elasticsearch Operator をインストールします。

    1. OpenShift Dedicated Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から Elasticsearch を選択し、Install をクリックします。
    3. Create Operator Subscription ページの A specific namespace on the cluster の下で openshift-logging を選択します。次に、Subscribe をクリックします。
  2. OperatorHub からクラスターロギング Operator をインストールします。

    1. OpenShift Dedicated Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から Cluster Logging を選択し、Install をクリックします。
    3. Create Operator Subscription ページの A specific namespace on the cluster の下で openshift-logging を選択します。次に、Subscribe をクリックします。
  3. Operator のインストールを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. Cluster Logging および Elasticsearch Operator が StatusInstallSucceeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。その後に Operator が InstallSucceeded メッセージと共にインストールされる場合、Failed メッセージを安全に無視することができます。

      いずれかの Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを行うには、以下を実行します。

      • OperatorsInstalled Operators ページに切り替え、Status 列でエラーまたは失敗の有無を確認します。
      • WorkloadsPods ページに切り替え、 openshift-logging プロジェクトの各 Pod で問題を報告しているログの有無を確認します。
  4. クラスターロギングインスタンスを作成し、デプロイします。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. インストールされた Cluster Logging Operator をクリックします。
    3. Overview タブで、Create Instance をクリックします。以下の YAML 定義を表示されるウィンドウに貼り付けます。

      クラスターロギングのカスタムリソース (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:
              requests:
                memory: 8G
        visualization:
          type: "kibana"
          kibana:
            replicas: 1
            nodeSelector:
              node-role.kubernetes.io/worker: ""
        curation:
          type: "curator"
          curator:
            schedule: "15 * * * *"
            nodeSelector:
              node-role.kubernetes.io/worker: ""
        collection:
          logs:
            type: "fluentd"
            fluentd: {}
            nodeSelector:
              node-role.kubernetes.io/worker: ""

    4. Create をクリックし、クラスターロギングおよび Elasticsearch カスタムリソースを作成するロギングインスタンスをデプロイします。
  5. クラスターロギングインスタンスの Pod がデプロイされていることを確認します。

    1. WorkloadsPods ページに切り替えます。
    2. 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
  6. OpenShift Dedicated Web コンソールの MonitoringLogging ページからクラスターロギングインターフェース Kibanaにアクセスします。

第3章 クラスターロギングの更新

OpenShift Dedicated クラスターを 4.2 から 4.3 に更新した後に、クラスターロギングを 4.2 から 4.3 にアップグレードする必要があります。

3.1. クラスターロギングの更新

OpenShift Dedicated クラスターの更新後に、Elasticsearch Operator および Cluster Logging Operator のサブスクリプションを更新して、クラスターロギングを 4.2 から 4.3 に更新できます。

重要

新規のログ転送機能によって導入された変更により、OpenShift Dedicated 4.3 リリース以降の out_forward のサポートが変更されました。OpenShift Dedicated 4.3 では、out_forward を設定するために ConfigMap を作成します。Fluentd ConfigMap の secure-forward.conf セクションに対するすべての更新は削除されます。

更新する前に out_forward プラグインを使用する場合、Fluentd ConfigMap から現在の secure-forward.conf セクションをコピーし、secure-forward ConfigMap の作成時にコピーされるデータを使用できます。

前提条件

  • クラスターを 4.2 から 4.3 に更新します。
  • クラスターロギングのステータスが正常であることを確認します。

    • すべての Pod が Ready 状態にある。
    • Elasticsearch クラスターが正常である。
  • オプションで、secure-forward ConfigMap を作成する必要がある場合に Fluentd ConfigMap から現在の secure-forward.conf セクションをコピーします。上記の注記を参照してください。

手順

  1. Elasticsearch Operator を更新します。

    1. Web コンソールで OperatorsInstalled Operators をクリックします。
    2. openshift-logging プロジェクトを選択します。
    3. Elasticsearch Operatorをクリックします。
    4. SubscriptionChannel をクリックします。
    5. Change Subscription Update Channel ウィンドウで 4.3 を選択し、Save をクリックします。
    6. 数秒待ってから OperatorsInstalled Operators をクリックします。

      Elasticsearch Operator が 4.3 と表示されます。以下は例になります。

      Elasticsearch Operator
      4.3.0-201909201915 provided
      by Red Hat, Inc
  2. Cluster Logging Operator を更新します。

    1. Web コンソールで OperatorsInstalled Operators をクリックします。
    2. openshift-logging プロジェクトを選択します。
    3. Cluster Logging Operatorをクリックします。
    4. SubscriptionChannel をクリックします。
    5. Change Subscription Update Channel ウィンドウで 4.3 を選択し、Save をクリックします。
    6. 数秒待ってから OperatorsInstalled Operators をクリックします。

      Cluster Logging Operator は 4.3 として表示されます。以下は例になります。

      Cluster Logging
      4.3.0-201909201915 provided
      by Red Hat, Inc
  3. ロギングコンポーネントを確認します。

    1. Elasticsearch Pod が 4.3 イメージを使用していることを確認します。

      $ oc get pod -o yaml -n openshift-logging --selector component=elasticsearch |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
    2. すべての 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
    3. Elasticsearch クラスターが正常であることを確認します。

      oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- es_cluster_health
      
      {
        "cluster_name" : "elasticsearch",
        "status" : "green",
      
      ....
    4. ロギングコレクター Pod が 4.3 イメージを使用していることを確認します。

      $ oc get pod -n openshift-logging --selector logging-infra=fluentd -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.3.0-202001081344
    5. Kibana Pod が 4.3 イメージを使用していることを確認します。

      $ oc get pod -n openshift-logging --selector logging-infra=kibana -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.3.0-202001081344
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.3.0-202001081344
    6. Curator CronJob が 4.3 イメージを使用していることを確認します。

      $ $ oc get CronJob curator -n openshift-logging -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-curator5:v4.3.0-202001081344

第4章 Kibana を使用したクラスターログの表示

クラスターロギングのインストールは Kibana Web コンソールをデプロイします。

4.1. Kibana の起動

Kibana は、ヒストグラム、線グラフ、円グラフ、ヒートマップ、ビルトインされた地理空間サポート、その他の視覚化機能を使用してログをクエリーし、検出し、視覚化するためのブラウザーベースのコンソールです。

手順

Kibana を起動するには、以下を実行します。

  1. OpenShift Dedicated コンソールで、MonitoringLogging をクリックします。
  2. OpenShift Dedicated コンソールにログインするために使用するものと同じ認証情報を使用してログインします。

    Kibana インターフェースが起動します。以下を実行することができます。

    • Discover ページを使用してデータを検索し、参照します。
    • Visualize ページを使用してデータのグラフを表示し、データをマップします。
    • Dashboard ページを使用してカスタムダッシュボードを作成し、表示します。

      Kibana インターフェースの使用および設定については、本書では扱いません。詳細については、Kibana のドキュメントを参照してください。

第5章 クラスターロギングのアンインストール

クラスターロギングを OpenShift Dedicated クラスターから削除することができます。

5.1. OpenShift Dedicated からのクラスターロギングのアンインストール

クラスターロギングをクラスターから削除できます。

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。

手順

クラスターロギングを削除するには、以下を実行します。

  1. 以下のコマンドを使用して、デプロイメント時に生成されたすべてのものを削除します。

    $ oc delete clusterlogging instance -n openshift-logging
  2. 以下のコマンドを使用して、Operator インスタンスの削除後も保持される Persistent Volume Claim(永続ボリューム要求、PVC)を削除します。

    $ oc delete pvc --all -n openshift-logging

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.