11.2. ログストレージのインストール


OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して、OpenShift Container Platform クラスターにログストアをデプロイできます。

注記

Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。

11.2.1. Loki ログストアのデプロイ

Loki Operator を使用して、OpenShift Container Platform クラスターに内部 Loki ログストアをデプロイできます。Loki Operator をインストールした後、シークレットを作成することで Loki オブジェクトストレージを設定し、LokiStack カスタムリソース (CR) を作成する必要があります。

11.2.1.1. Loki デプロイメントのサイズ

Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。

重要

デプロイメントサイズの 1x の数は変更できません。

表11.1 Loki のサイズ
 1x.demo1x.extra-small1x.small1x.medium

Data transfer

デモ使用のみ

100 GB/日

500 GB/日

2 TB/日

1 秒あたりのクエリー数 (QPS)

デモ使用のみ

200 ミリ秒で 1 - 25 QPS

200 ミリ秒で 25 - 50 QPS

200 ミリ秒で 25 - 75 QPS

レプリケーション係数

なし

2

2

2

合計 CPU 要求

なし

仮想 CPU 14 個

仮想 CPU 34 個

仮想 CPU 54 個

ルーラーを使用する場合の合計 CPU リクエスト

なし

仮想 CPU 16 個

仮想 CPU 42 個

仮想 CPU 70 個

合計メモリー要求

なし

31 Gi

67 Gi

139 Gi

ルーラーを使用する場合の合計メモリーリクエスト

なし

35Gi

83Gi

171Gi

合計ディスク要求

40Gi

430 Gi

430 Gi

590Gi

ルーラーを使用する場合の合計ディスクリクエスト

80Gi

750Gi

750Gi

910Gi

11.2.1.2. Web コンソールを使用してロギングと Loki Operator をインストールする

OpenShift Container Platform クラスターにログをインストールして設定するには、まずログストレージ用の Loki Operator などの Operator をインストールする必要があります。これは、Web コンソールの Operator Hub から実行できます。

前提条件

  • サポートされているオブジェクトストア (AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation) にアクセスできる。
  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators OperatorHub に移動します。
  2. Filter by keyword フィールドに Loki Operator と入力します。使用可能な Operator のリストで Loki Operator をクリックし、Install をクリックします。

    重要

    Community Loki Operator は Red Hat ではサポートされていません。

  3. Update channel として stable または stable-x.y を選択します。

    注記

    stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-x.y に変更する必要があります。x.y は、インストールしたログのメジャーバージョンとマイナーバージョンを表します。たとえば、stable-5.7 です。

    Loki Operator はグローバルオペレーターグループ namespace である openshift-operators-redhat にデプロイする必要があるため、Installation modeInstalled Namespace がすでに選択されています。この namespace がない場合は、自動的に作成されます。

  4. Enable Operator-recommended cluster monitoring on this namespace. を選択します。

    このオプションは、Namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

  5. Update approvaAutomatic を選択し、Install をクリックします。

    サブスクリプションの承認ストラテジーが Automatic に設定されている場合、アップグレードプロセスは、選択したチャネルで新規 Operator バージョンが利用可能になるとすぐに開始します。承認ストラテジーが Manual に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。

  6. Red Hat OpenShift Logging Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、Operators OperatorHub をクリックします。
    2. 利用可能な Operator のリストから Red Hat OpenShift Logging を選択し、Install をクリックします。
    3. A specific namespace on the clusterInstallation Mode で選択されていることを確認します。
    4. Operator recommended namespaceInstalled Namespaceopenshift-logging になっていることを確認します。
    5. Enable Operator recommended cluster monitoring on this namespace を選択します。

      このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-logging namespace を収集できるように、このオプションを選択する必要があります。

    6. Update Channel として stable-5.y を選択します。
    7. Approval Strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
    8. Install をクリックします。
  7. Operators Installed Operators ページに移動します。All instances タブをクリックします。
  8. Create new ドロップダウンリストから、LokiStack を選択します。
  9. YAML view を選択し、次のテンプレートを使用して LokiStack CR を作成します。

    LokiStack CR の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging 2
    spec:
      size: 1x.small 3
      storage:
        schemas:
        - version: v12
          effectiveDate: "2022-06-01"
        secret:
          name: logging-loki-s3 4
          type: s3 5
          credentialMode: 6
      storageClassName: <storage_class_name> 7
      tenants:
        mode: openshift-logging 8

    1
    logging-loki という名前を使用します。
    2
    openshift-logging namespace を指定する必要があります。
    3
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    4
    ログストアシークレットの名前を指定します。
    5
    対応するストレージタイプを指定します。
    6
    任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得された有効期間の短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。token-cco は、Loki がマネージド STS モードで実行し、STS/WIF クラスターで CCO を使用している場合のデフォルト値です。
    7
    一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
    8
    LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
    重要

    デプロイメントサイズの 1x の数は変更できません。

  10. Create をクリックします。
  11. OpenShift Logging インスタンスを作成します。

    1. Administration Custom Resource Definitions ページに切り替えます。
    2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
    3. Custom Resource Definition details ページで、Actions メニューから View Instances を選択します。
    4. ClusterLoggings ページで、Create ClusterLogging をクリックします。

      データを読み込むためにページの更新が必要になる場合があります。

    5. YAML フィールドで、コードを以下に置き換えます。

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        name: instance 1
        namespace: openshift-logging 2
      spec:
        collection:
          type: vector
        logStore:
          lokistack:
            name: logging-loki
          retentionPolicy:
            application:
              maxAge: 7d
            audit:
              maxAge: 7d
            infra:
              maxAge: 7d
          type: lokistack
        visualization:
          type: ocp-console
          ocpConsole:
            logsLimit: 15
      
        managementState: Managed
      1
      名前は instance にする必要があります。
      2
      namespace は openshift-logging にする必要があります。

検証

  1. Operators Installed Operators に移動します。
  2. openshift-logging プロジェクトが選択されていることを確認します。
  3. Status 列に、緑色のチェックマークおよび InstallSucceeded と、Up to date というテキストが表示されていることを確認します。
注記

インストールが完了する前に、Operator に Failed ステータスが表示される場合があります。InstallSucceeded メッセージが表示されて Operator のインストールが完了した場合は、ページを更新します。

11.2.1.3. Web コンソールを使用して Loki オブジェクトストレージのシークレットを作成する

Loki オブジェクトストレージを設定するには、シークレットを作成する必要があります。OpenShift Container Platform Web コンソールを使用してシークレットを作成できます。

前提条件

  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Loki Operator がインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Workloads Secrets に移動します。
  2. Create ドロップダウンリストから、From YAML を選択します。
  3. access_key_id フィールドと access_key_secret フィールドを使用して認証情報を指定し、bucketnamesendpoint、および region フィールドを使用してオブジェクトの保存場所を定義するシークレットを作成します。次の例では、AWS が使用されています。

    Secret オブジェクトの例

    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

11.2.2. 短期認証情報を使用するクラスターに Loki ログストアのデプロイ

一部のストレージプロバイダーでは、インストール時に CCO ユーティリティー (ccoctl) を使用して、短期認証情報を実装できます。これらの認証情報は、OpenShift Container Platform クラスターの外部で作成および管理されます。コンポーネントの短期認証情報を使用した手動モード

注記

この認証情報ストラテジーを使用するクラスターでは、Loki Operator の新規インストール中に短期認証情報の認証を設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように設定することはできません。

11.2.2.1. ワークロードアイデンティティーフェデレーション

ワークロードアイデンティティーフェデレーションを使用すると、有効期間の短いトークンを使用してクラウドベースのログストアに対して認証できます。

前提条件

  • OpenShift Container Platform 4.14 以降
  • Logging 5.9 以降

手順

  • OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が CredentialsRequest オブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。
  • OpenShift CLI (oc) を使用して Loki Operator をインストールする場合は、次の例に示すように、ストレージプロバイダーに適したテンプレートを使用してサブスクリプションオブジェクトを手動で作成する必要があります。この認証ストラテジーは、指定のストレージプロバイダーでのみサポートされます。

Azure のサンプルサブスクリプション

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

AWS のサンプルサブスクリプション

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

11.2.2.2. Web コンソールを使用して LokiStack カスタムリソースを作成する

OpenShift Container Platform Web コンソールを使用して、LokiStack カスタムリソース (CR) を作成できます。

前提条件

  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Loki Operator がインストールされている。

手順

  1. Operators Installed Operators ページに移動します。All instances タブをクリックします。
  2. Create new ドロップダウンリストから、LokiStack を選択します。
  3. YAML view を選択し、次のテンプレートを使用して LokiStack CR を作成します。

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging
    spec:
      size: 1x.small 2
      storage:
        schemas:
          - effectiveDate: '2023-10-15'
            version: v13
        secret:
          name: logging-loki-s3 3
          type: s3 4
          credentialMode: 5
      storageClassName: <storage_class_name> 6
      tenants:
        mode: openshift-logging
    1
    logging-loki という名前を使用します。
    2
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    3
    ログストレージに使用するシークレットを指定します。
    4
    対応するストレージタイプを指定します。
    5
    任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco がデフォルト値です。
    6
    一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。

11.2.2.3. CLI を使用してロギングと Loki Operator をインストールする

OpenShift Container Platform クラスターにログをインストールして設定するには、まずログストレージ用の Loki Operator などの Operator をインストールする必要があります。これは、OpenShift Container Platform CLI から実行できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • サポートされているオブジェクトストアにアクセスできる。例: AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation。
注記

stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-x.y に変更する必要があります。x.y は、インストールしたログのメジャーバージョンとマイナーバージョンを表します。たとえば、stable-5.7 です。

  1. Loki Operator の Namespace オブジェクトを作成します。

    Namespace オブジェクトの例

    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-redhat namespace を指定する必要があります。メトリクスとの競合が発生する可能性を防ぐには、Prometheus のクラスターモニタリングスタックを、openshift-operators namespace からではなく、openshift-operators-redhat namespace からメトリクスを収集するように設定する必要があります。openshift-operators namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリックと同じ名前でメトリックを公開する可能性があるため、これによって競合が生じる可能性があります。
    2
    クラスターモニタリングが openshift-operators-redhat namespace をスクレイピングできるようにするために、示されているラベルを指定する文字列値。
  2. 次のコマンドを実行して、Namespace オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  3. Loki Operator の Subscription オブジェクトを作成します。

    Subscription オブジェクトの例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: loki-operator
      namespace: openshift-operators-redhat 1
    spec:
      channel: stable 2
      name: loki-operator
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace

    1
    openshift-operators-redhat namespace を指定する必要があります。
    2
    チャネルとして stable または stable-5.<y> を指定します。
    3
    redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。
  4. 以下のコマンドを実行して Subscription オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  5. Red Hat OpenShift Logging Operator の namespace オブジェクトを作成します。

    namespace オブジェクトの例

    apiVersion: v1
    kind: Namespace
    metadata:
    name: openshift-logging 1
    annotations:
        openshift.io/node-selector: ""
    labels:
        openshift.io/cluster-logging: "true"
        openshift.io/cluster-monitoring: "true" 2

    1
    Red Hat OpenShift Logging Operator は、openshift-logging namespace にのみデプロイ可能です。
    2
    クラスターモニタリングが openshift-operators-redhat namespace をスクレイピングできるようにするために、示されているラベルを指定する文字列値。
  6. 次のコマンドを実行して、namespace オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  7. OperatorGroup オブジェクトを作成します。

    OperatorGroup オブジェクトのサンプル

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: cluster-logging
      namespace: openshift-logging 1
    spec:
      targetNamespaces:
      - openshift-logging

    1
    openshift-logging namespace を指定する必要があります。
  8. 以下のコマンドを実行して OperatorGroup オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  9. Subscription オブジェクトを作成します。

    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
    1
    openshift-logging namespace を指定する必要があります。
    2
    チャネルとして stable または stable-5.<y> を指定します。
    3
    redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。
  10. 以下のコマンドを実行して Subscription オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  11. LokiStack CR を作成します。

    LokiStack CR の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging 2
    spec:
      size: 1x.small 3
      storage:
        schemas:
        - version: v12
          effectiveDate: "2022-06-01"
        secret:
          name: logging-loki-s3 4
          type: s3 5
          credentialMode: 6
      storageClassName: <storage_class_name> 7
      tenants:
        mode: openshift-logging 8

    1
    logging-loki という名前を使用します。
    2
    openshift-logging namespace を指定する必要があります。
    3
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    4
    ログストアシークレットの名前を指定します。
    5
    対応するストレージタイプを指定します。
    6
    任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco がデフォルト値です。
    7
    一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
    8
    LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
  12. 次のコマンドを実行して、LokiStack CR オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  13. ClusterLogging CR オブジェクトを作成します。

    ClusterLogging CR オブジェクトの例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance 1
      namespace: openshift-logging 2
    spec:
      collection:
        type: vector
      logStore:
        lokistack:
          name: logging-loki
        retentionPolicy:
          application:
            maxAge: 7d
          audit:
            maxAge: 7d
          infra:
            maxAge: 7d
        type: lokistack
      visualization:
        type: ocp-console
        ocpConsole:
          logsLimit: 15
      managementState: Managed

    1
    名前は instance にする必要があります。
    2
    namespace は openshift-logging にする必要があります。
  14. 次のコマンドを実行して ClusterLogging CR オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  15. 次のコマンドを実行して、インストールを確認します。

    $ oc get pods -n openshift-logging

    出力例

    $ oc get pods -n openshift-logging
    NAME                                               READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-fb7f7cf69-8jsbq           1/1     Running   0          98m
    collector-222js                                    2/2     Running   0          18m
    collector-g9ddv                                    2/2     Running   0          18m
    collector-hfqq8                                    2/2     Running   0          18m
    collector-sphwg                                    2/2     Running   0          18m
    collector-vv7zn                                    2/2     Running   0          18m
    collector-wk5zz                                    2/2     Running   0          18m
    logging-view-plugin-6f76fbb78f-n2n4n               1/1     Running   0          18m
    lokistack-sample-compactor-0                       1/1     Running   0          42m
    lokistack-sample-distributor-7d7688bcb9-dvcj8      1/1     Running   0          42m
    lokistack-sample-gateway-5f6c75f879-bl7k9          2/2     Running   0          42m
    lokistack-sample-gateway-5f6c75f879-xhq98          2/2     Running   0          42m
    lokistack-sample-index-gateway-0                   1/1     Running   0          42m
    lokistack-sample-ingester-0                        1/1     Running   0          42m
    lokistack-sample-querier-6b7b56bccc-2v9q4          1/1     Running   0          42m
    lokistack-sample-query-frontend-84fb57c578-gq2f7   1/1     Running   0          42m

11.2.2.4. CLI を使用して Loki オブジェクトストレージのシークレットを作成する

Loki オブジェクトストレージを設定するには、シークレットを作成する必要があります。これは、OpenShift CLI (oc) を使用して実行できます。

前提条件

  • 管理者権限がある。
  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを使用して、証明書とキーファイルが含まれるディレクトリーにシークレットを作成できます。

    $ oc create secret generic -n openshift-logging <your_secret_name> \
     --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>
注記

最良の結果を得るには、generic または opaque シークレットを使用してください。

検証

  • 次のコマンドを実行して、シークレットが作成されたことを確認します。

    $ oc get secrets

11.2.2.5. CLI を使用して LokiStack カスタムリソースを作成する

OpenShift CLI (oc) を使用して、LokiStack カスタムリソース (CR) を作成できます。

前提条件

  • 管理者権限がある。
  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. LokiStack CR を作成します。

    LokiStack CR の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging
    spec:
      size: 1x.small 2
      storage:
        schemas:
          - effectiveDate: '2023-10-15'
            version: v13
        secret:
          name: logging-loki-s3 3
          type: s3 4
          credentialMode: 5
      storageClassName: <storage_class_name> 6
      tenants:
        mode: openshift-logging

    1
    logging-loki という名前を使用します。
    2
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    3
    ログストレージに使用するシークレットを指定します。
    4
    対応するストレージタイプを指定します。
    5
    任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco がデフォルト値です。
    6
    一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
  2. 次のコマンドを実行して、LokiStack CR を適用します。

検証

  • 次のコマンドを実行して出力を観察し、openshift-logging プロジェクト内の Pod をリスト表示してインストールを確認します。

    $ oc get pods -n openshift-logging

    次のリストのように、ロギングコンポーネント用の Pod が複数表示されていることを確認します。

    出力例

    NAME                                           READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-78fddc697-mnl82       1/1     Running   0          14m
    collector-6cglq                                2/2     Running   0          45s
    collector-8r664                                2/2     Running   0          45s
    collector-8z7px                                2/2     Running   0          45s
    collector-pdxl9                                2/2     Running   0          45s
    collector-tc9dx                                2/2     Running   0          45s
    collector-xkd76                                2/2     Running   0          45s
    logging-loki-compactor-0                       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-25j9g       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-xwjs6       1/1     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-hjhl4          2/2     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-qjtlb          2/2     Running   0          8m2s
    logging-loki-index-gateway-0                   1/1     Running   0          8m2s
    logging-loki-index-gateway-1                   1/1     Running   0          7m29s
    logging-loki-ingester-0                        1/1     Running   0          8m2s
    logging-loki-ingester-1                        1/1     Running   0          6m46s
    logging-loki-querier-f5cf9cb87-9fdjd           1/1     Running   0          8m2s
    logging-loki-querier-f5cf9cb87-fp9v5           1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-lfvbc   1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-tjf9k   1/1     Running   0          8m2s
    logging-view-plugin-79448d8df6-ckgmx           1/1     Running   0          46s

11.2.3. Loki オブジェクトストレージ

Loki Operator は、AWS S3 だけでなく、MinioOpenShift Data Foundation などの他の S3 互換オブジェクトストアもサポートしています。AzureGCS、および Swift もサポートされています。

Loki ストレージの推奨命名法は、logging-loki-<your_storage_provider> です。

次の表は、各ストレージプロバイダーの LokiStack カスタムリソース (CR) 内の type 値を示しています。詳細は、ストレージプロバイダーに関するセクションを参照してください。

表11.2 シークレットタイプのクイックリファレンス
ストレージプロバイダーシークレットの type

AWS

s3

Azure

azure

Google Cloud

gcs

Minio

s3

OpenShift Data Foundation

s3

Swift

swift

11.2.3.1. AWS ストレージ

前提条件

手順

  • 次のコマンドを実行して、logging-loki-aws という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-aws \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<aws_bucket_endpoint>" \
      --from-literal=access_key_id="<aws_access_key_id>" \
      --from-literal=access_key_secret="<aws_access_key_secret>" \
      --from-literal=region="<aws_region_of_your_bucket>"
11.2.3.1.1. STS 対応クラスターの AWS ストレージ

クラスターで STS が有効になっている場合、Cloud Credential Operator (CCO) によって AWS トークンを使用した短期認証がサポートされます。

次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。

$ oc -n openshift-logging create secret generic "logging-loki-aws" \
--from-literal=bucketnames="<s3_bucket_name>" \
--from-literal=region="<bucket_region>" \
--from-literal=audience="<oidc_audience>" 1
1
任意のアノテーション。デフォルト値は openshift です。

11.2.3.2. Azure ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Azure 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-azure という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-azure \
      --from-literal=container="<azure_container_name>" \
      --from-literal=environment="<azure_environment>" \ 1
      --from-literal=account_name="<azure_account_name>" \
      --from-literal=account_key="<azure_account_key>"
    1
    サポートされている環境値は、AzureGlobalAzureChinaCloudAzureGermanCloudAzureUSGovernment です。
11.2.3.2.1. Microsoft Entra Workload ID 対応クラスター用の Azure ストレージ

クラスターで Microsoft Entra Workload ID が有効になっている場合、Cloud Credential Operator (CCO) は Workload ID を使用した短期認証をサポートします。

次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。

$ oc -n openshift-logging create secret generic logging-loki-azure \
--from-literal=environment="<azure_environment>" \
--from-literal=account_name="<storage_account_name>" \
--from-literal=container="<container_name>"

11.2.3.3. Google Cloud Platform ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Google Cloud Platform (GCP) 上に プロジェクト を作成している。
  • 同じプロジェクト内に バケット を作成している。
  • 同じプロジェクト内に GCP 認証用の サービスアカウント を作成している。

手順

  1. GCP から受け取ったサービスアカウントの認証情報を key.json という名前のファイルにコピーします。
  2. 次のコマンドを実行して、logging-loki-gcs という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-gcs \
      --from-literal=bucketname="<bucket_name>" \
      --from-file=key.json="<path/to/key.json>"

11.2.3.4. Minio ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Minio がクラスターにデプロイされている。
  • Minio 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-minio という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-minio \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<minio_bucket_endpoint>" \
      --from-literal=access_key_id="<minio_access_key_id>" \
      --from-literal=access_key_secret="<minio_access_key_secret>"

11.2.3.5. OpenShift Data Foundation ストレージ

前提条件

手順

  1. openshift-logging namespace に ObjectBucketClaim カスタムリソースを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: loki-bucket-odf
      namespace: openshift-logging
    spec:
      generateBucketName: loki-bucket-odf
      storageClassName: openshift-storage.noobaa.io
  2. 次のコマンドを実行して、関連付けられた ConfigMap オブジェクトからバケットのプロパティーを取得します。

    BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
    BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
    BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')
  3. 次のコマンドを実行して、関連付けられたシークレットからバケットアクセスキーを取得します。

    ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
    SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
  4. 次のコマンドを実行して、logging-loki-odf という名前のオブジェクトストレージシークレットを作成します。

    $ oc create -n openshift-logging secret generic logging-loki-odf \
    --from-literal=access_key_id="<access_key_id>" \
    --from-literal=access_key_secret="<secret_access_key>" \
    --from-literal=bucketnames="<bucket_name>" \
    --from-literal=endpoint="https://<bucket_host>:<bucket_port>"

11.2.3.6. Swift ストレージ:

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Swift 上で バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-swift という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>"
  • 必要に応じて、次のコマンドを実行して、プロジェクト固有のデータ、リージョン、またはその両方を指定できます。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>" \
      --from-literal=project_id="<swift_project_id>" \
      --from-literal=project_name="<swift_project_name>" \
      --from-literal=project_domain_id="<swift_project_domain_id>" \
      --from-literal=project_domain_name="<swift_project_domain_name>" \
      --from-literal=region="<swift_region>"

11.2.4. Elasticsearch ログストアのデプロイ

OpenShift Elasticsearch Operator を使用して、OpenShift Container Platform クラスターに内部 Elasticsearch ログストアをデプロイできます。

注記

Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。

11.2.4.1. Elasticsearch のストレージに関する考慮事項

永続ボリュームがそれぞれの Elasticsearch デプロイメント設定に必要です。OpenShift Container Platform では、これは永続ボリューム要求 (PVC) を使用して実行されます。

注記

永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

OpenShift Elasticsearch Operator は Elasticsearch リソース名を使用して PVC に名前を付けます。

Fluentd は systemd ジャーナル および /var/log/containers/*.log から Elasticsearch にログを送信します。

Elasticsearch では、大規模なマージ操作を実行するのに十分なメモリーが必要です。十分なメモリーがない場合は、応答しなくなります。この問題を回避するには、必要なアプリケーションのログデータの量を評価し、空き容量の約 2 倍を割り当てます。

デフォルトで、ストレージ容量が 85% に達すると、Elasticsearch は新規データのノードへの割り当てを停止します。90% になると、Elasticsearch は可能な場合に既存のシャードをそのノードから他のノードに移動しようとします。ただし、空き容量のレベルが 85% 未満のノードがない場合、Elasticsearch は新規インデックスの作成を拒否し、ステータスは RED になります。

注記

これらの基準値 (高い値および低い値を含む) は現行リリースにおける Elasticsearch のデフォルト値です。これらのデフォルト値は変更できます。アラートは同じデフォルト値を使用しますが、これらの値をアラートで変更することはできません。

11.2.4.2. Web コンソールを使用した OpenShift Elasticsearch Operator のインストール

OpenShift Elasticsearch Operator は、OpenShift Logging によって使用される Elasticsearch クラスターを作成し、管理します。

前提条件

  • Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、ClusterLogging カスタムリソースで指定しない限り、メモリー要求および制限の両方に 16GB 以上のメモリーが必要です。

    初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリー (各 Elasticsearch ノードに最大 64GB) を使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。

    Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境には推奨されません。

  • Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

手順

  1. OpenShift Container Platform Web コンソールで、Operators OperatorHub をクリックします。
  2. 利用可能な Operator のリストから OpenShift Elasticsearch OperatorInstall の順にクリックします。
  3. All namespaces on the clusterInstallation mode で選択されていることを確認します。
  4. openshift-operators-redhatInstalled Namespace で選択されていることを確認します。

    openshift-operators-redhat namespace を指定する必要があります。openshift-operators namespace にはコミュニティーの Operator が含まれている場合があります。コミュニティーの Operator は信頼されたものではなく、OpenShift Container Platform のメトリクスと同じ名前のメトリクスを公開する可能性があります。これにより、競合が発生することがあります。

  5. Enable operator recommended cluster monitoring on this namespace を選択します。

    このオプションは、Namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

  6. Update Channel として stable-5.x を選択します。
  7. Update approval strategy を選択します。

    • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
    • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
  8. Install をクリックします。

検証

  1. Operators Installed Operators ページに切り替えて、OpenShift Elasticsearch Operator がインストールされていることを確認します。
  2. StatusSucceeded の状態で、OpenShift Elasticsearch Operator がすべてのプロジェクトにリスト表示されていることを確認します。

11.2.4.3. CLI を使用して OpenShift Elasticsearch Operator をインストールする

OpenShift CLI (oc) を使用して、OpenShift Elasticsearch Operator をインストールできます。

前提条件

  • Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

    Elasticsearch はメモリー集約型アプリケーションです。デフォルトで、OpenShift Container Platform はメモリー要求および 16 GB の制限を持つ 3 つの Elasticsearch ノードをインストールします。OpenShift Container Platform ノードの最初の 3 つのセットには、Elasticsearch をクラスター内で実行するのに十分なメモリーがない可能性があります。Elasticsearch に関連するメモリーの問題が発生した場合は、既存ノードのメモリーを増やすのではなく、Elasticsearch ノードをクラスターにさらに追加します。

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 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-redhat namespace を指定する必要があります。メトリクスとの競合が発生する可能性を防ぐには、Prometheus のクラスターモニタリングスタックを、openshift-operators namespace からではなく、openshift-operators-redhat namespace からメトリクスを収集するように設定します。openshift-operators namespace にはコミュニティーの Operator が含まれている場合があります。コミュニティーの Operator は信頼されたものではなく、メトリクスと同じ名前のメトリクスを公開する可能性があります。これにより、競合が発生することがあります。
    2
    String。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このラベルを上記のように指定する必要があります。
  2. 次のコマンドを実行して、Namespace オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  3. OperatorGroup オブジェクトを、YAML ファイルとして作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-operators-redhat
      namespace: openshift-operators-redhat 1
    spec: {}
    1
    openshift-operators-redhat namespace を指定する必要があります。
  4. 以下のコマンドを実行して OperatorGroup オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  5. OpenShift Elasticsearch Operator に namespace をサブスクライブするための Subscription オブジェクトを作成します。

    Subscription の例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: elasticsearch-operator
      namespace: openshift-operators-redhat 1
    spec:
      channel: stable-x.y 2
      installPlanApproval: Automatic 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace
      name: elasticsearch-operator

    1
    openshift-operators-redhat namespace を指定する必要があります。
    2
    チャネルとして stable または stable-x.y を指定します。以下の注意点を参照してください。
    3
    Automatic により、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。Manual には、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
    4
    redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれるネットワークが制限された環境でインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成される CatalogSource オブジェクトの名前を指定します。
    注記

    stable を指定すると、最新の安定したリリースの現行バージョンがインストールされます。stableinstallPlanApproval: "Automatic" とともに使用すると、Operator が最新の安定したメジャーリリースとマイナーリリースに自動的にアップグレードされます。

    stable-x.y を指定すると、特定のメジャーリリースの現在のマイナーバージョンがインストールされます。stable-x.yinstallPlanApproval: "Automatic" と併せて使用すると、Operator がメジャーリリース内の最新の stable マイナーリリースに自動的にアップグレードされます。

  6. 次のコマンドを実行して、サブスクリプションを適用します。

    $ oc apply -f <filename>.yaml

    OpenShift Elasticsearch Operator は openshift-operators-redhat namespace にインストールされ、クラスター内の各プロジェクトにコピーされます。

検証

  1. 以下のコマンドを実行します。

    $ oc get csv -n --all-namespaces
  2. 出力を観察し、OpenShift Elasticsearch Operator の Pod が各 namespace に存在することを確認します。

    出力例

    NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
    default                                            elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-node-lease                                    elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-public                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-system                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    non-destructive-test                               elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver-operator                       elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver                                elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    ...

11.2.5. ログストレージの設定

ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログストレージのタイプを設定できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator と内部ログストア (LokiStack または Elasticsearch) がインストールされている。
  • ClusterLogging CR が作成されている。
注記

Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。

手順

  1. ClusterLogging CR の logStore 仕様を変更します。

    ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      logStore:
        type: <log_store_type> 1
        elasticsearch: 2
          nodeCount: <integer>
          resources: {}
          storage: {}
          redundancyPolicy: <redundancy_type> 3
        lokistack: 4
          name: {}
    # ...

    1
    ログストアのタイプを指定します。これは lokistack または elasticsearch のいずれかです。
    2
    Elasticsearch ログストアの任意の設定オプション。
    3
    冗長性のタイプを指定します。この値には、ZeroRedundancySingleRedundancyMultipleRedundancy、または FullRedundancy を指定できます。
    4
    LokiStack の任意の設定オプション。

    LokiStack をログストアとして指定する ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      managementState: Managed
      logStore:
        type: lokistack
        lokistack:
          name: logging-loki
    # ...

  2. 次のコマンドを実行して、ClusterLogging CR を適用します。

    $ oc apply -f <filename>.yaml
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.