検索
サポートコンソール開発者トライアルの開始お問い合わせ

2.3. Logging 6.0 へのアップグレード

download PDF

ロギング v6.0 は以前のリリースからの大幅なアップグレードであるため、クラスターロギングの目標が複数長くなります。

  • ロギングコンポーネントを管理するための個別の Operator の概要（例：コレクター、ストレージ、可視化）。
  • Elastic 製品(Elasticsearch、Kibana)に基づくマネージドログストレージおよび可視化のサポートの削除。
  • Fluentd ログコレクターの実装は非推奨です。
  • ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io リソースのサポートの削除。
注記

cluster-logging-operator は自動アップグレードプロセスを提供しません。

ログの収集、転送、およびストレージのさまざまな設定を指定すると、cluster-logging-operator では自動アップグレードは提供されません。このドキュメントでは、管理者が既存の ClusterLogging.logging.openshift.io および ClusterLogForwarder.logging.openshift.io 仕様を新規 API に変換する方法について説明します。一般的なユースケース用に移行した ClusterLogForwarder.observability.openshift.io リソースの例が含まれています。

2.3.1. oc explain コマンドの使用

oc explain コマンドは、カスタムリソース(CR)内のフィールドの詳細な説明を提供する OpenShift CLI oc の必須ツールです。このコマンドは、OpenShift クラスターのリソースを設定またはトラブルシューティングする管理者および開発者にとって非常に重要です。

2.3.1.1. リソースの説明

oc description は、特定のオブジェクトに関連する すべてのフィールドの詳細な説明を提供します。これには、Pod やサービスなどの標準リソースや、Operator で定義されたステートフルセットやカスタムリソースなどの複雑なエンティティーが含まれます。

ClusterLogForwarder カスタムリソースの outputs フィールドのドキュメントを表示するには、以下を使用できます。 

$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs
注記

clusterlogforwarder の代わりに、短い形式の obsclf を使用できます。

これにより、これらのフィールドのタイプ、デフォルト値、および関連するサブフィールドなど、これらのフィールドに関する詳細情報が表示されます。

2.3.1.2. 階層構造

このコマンドは、リソースフィールドの構造を階層形式で表示し、異なる設定オプション間の関係を明確にします。

たとえば、LokiStack カスタムリソースの ストレージ 設定にドリルダウンする方法を次に示します。 

$ oc explain lokistacks.loki.grafana.com
$ oc explain lokistacks.loki.grafana.com.spec
$ oc explain lokistacks.loki.grafana.com.spec.storage
$ oc explain lokistacks.loki.grafana.com.spec.storage.schemas

各コマンドは、リソース仕様のより深いレベルを表示し、構造を明確にします。

2.3.1.3. タイプ情報

oc explain は各フィールドのタイプ（文字列、整数、ブール値など）も示し、リソース定義で正しいデータタイプが使用されていることを確認できます。

以下に例を示します。 

$ oc explain lokistacks.loki.grafana.com.spec.size

これは、整数値を使用して サイズ を定義する必要があることを示しています。

2.3.1.4. デフォルト値

該当する場合は、コマンドはフィールドのデフォルト値を表示し、明示的に指定されていない場合に使用される値に関する洞察を提供します。

ここでも、例として lokistacks.loki.grafana.com を使用します。 

$ oc explain lokistacks.spec.template.distributor.replicas

出力例

GROUP:      loki.grafana.com
KIND:       LokiStack
VERSION:    v1

FIELD: replicas <integer>

DESCRIPTION:
    Replicas defines the number of replica pods of the component.

2.3.2. ログのストレージ

本リリースで利用可能な唯一の管理対象ログストレージソリューションは Lokistack で、loki-operator によって管理されます。このソリューションは、以前はマネージド Elasticsearch オファリングの優先されるものとして利用可能でしたが、デプロイメントプロセスでは変更されません。

重要

elasticsearch-operator によって提供される既存の Red Hat マネージド Elasticsearch または Kibana デプロイメントを引き続き使用するには、elasticsearch という名前の Elasticsearch リソースと、同じ namespace 内の instance という名前の ClusterLogging リソースを削除する前に、openshift-logging namespace の kibana という名前の Kibana リソースから所有者参照を削除します。

  1. ClusterLogging を一時的に Unmanagedに設定 

    $ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge

  2. Elasticsearch リソースからの ClusterLogging ownerReferences の削除

    以下のコマンドにより、ClusterLogging が Elasticsearch リソースを所有することがなくなります。ClusterLogging リソースの logStore フィールドが更新されても Elasticsearch リソースに影響を与えなくなりました。 

    $ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge

  3. Kibana リソースからの ClusterLogging ownerReferences の削除

    以下のコマンドは、ClusterLogging が Kibana リソースを所有しなくなったことを確認します。ClusterLogging リソースの visualization フィールドが更新されても Kibana リソースに影響を与えなくなりました。 

    $ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
  4. ClusterLogging を Managed状態に設定します。 
$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge

2.3.3. ログの可視化

ログビジュアライゼーション用の OpenShift コンソール UI プラグインが、cluster-logging-operator から cluster-observability-operator に移動されました。

2.3.4. ログの収集および転送

ログの収集および転送の設定は、observability.openshift.io API グループの一部として、新しい API で指定されるようになりました。以下のセクションでは、古い API リソースとの相違点を重点的に説明します。

注記

Vector は唯一のサポートされているコレクター実装です。

2.3.5. Management、Resource Allocation、およびワークロードのスケジュール

管理状態(Managed （マネージド)、Unmanaged など）、リソース要求および制限、容認、およびノードの選択が新規の ClusterLogForwarder API の一部になりました。

以前の設定

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
  managementState: "Managed"
  collection:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

現在の設定

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  managementState: Managed
  collector:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

2.3.6. 入力仕様

入力仕様は、ClusterLogForwarder 仕様のオプションの部分です。管理者は、引き続き アプリケーション、インフラストラクチャー、および 監査 の事前定義された値を使用し、これらのソースを収集できます。

2.3.6.1. アプリケーションの入力

namespace とコンテナーの包含と除外が単一のフィールドに統合されました。

5.9 名前空間とコンテナーを使用したアプリケーション入力には、と除外が含まれています。

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       namespaces:
       - foo
       - bar
       includes:
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

Namespace と Container が含まれる 6.0 アプリケーション入力には、包含と除外が含まれています。

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       includes:
       - namespace: foo
       - namespace: bar
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

注記

アプリケーション、インフラストラクチャー、および 監査 は予約語であり、入力を定義するときに名前として使用することはできません。

2.3.6.2. 入力 Receivers

入力レシーバーの変更点には、以下が含まれます。

  • レシーバーレベルでのタイプの明示的な設定。
  • ポート設定が受信側レベルに移動します。

5.9 入力 Receivers

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    receiver:
      http:
        port: 8443
        format: kubeAPIAudit
  - name: a-syslog
    receiver:
      type: syslog
      syslog:
        port: 9442

6.0 入力 Receivers

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    type: receiver
    receiver:
      type: http
      port: 8443
      http:
        format: kubeAPIAudit
  - name: a-syslog
    type: receiver
    receiver:
      type: syslog
      port: 9442

2.3.7. 出力の仕様

出力仕様に対する高度な変更には、以下が含まれます。

  • URL 設定は各出力タイプの仕様に移動しました。
  • チューニングパラメーターは各出力タイプの仕様に移動しました。
  • TLS 設定と認証の分離
  • TLS および認証用のキーおよびシークレット/configmap の明示的な設定。

2.3.8. シークレットおよび TLS 設定

シークレットおよび TLS 設定は、出力ごとに認証と TLS 設定に分割されるようになりました。これらは、管理者に依存して認識されたキーでシークレットを定義するのではなく、仕様で明示的に定義する必要があります。TLS と認可設定をアップグレードするには、管理者は既存のシークレットを引き続き使用するために、以前に認識された鍵を理解する必要があります。以下のセクションでは、既存の Red Hat が管理するログストレージソリューションに転送するために ClusterLogForwarder シークレットを設定する方法について詳しく説明します。

2.3.9. Red Hat マネージド Elasticsearch

Red Hat Managed Elasticsearch への v5.9 転送

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: elasticsearch

Red Hat Managed Elasticsearch への v6.0 転送

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-elasticsearch
    type: elasticsearch
    elasticsearch:
      url: https://elasticsearch:9200
      version: 6
      index: <log_type>-write-{+yyyy.MM.dd}
    tls:
      ca:
        key: ca-bundle.crt
        secretName: collector
      certificate:
        key: tls.crt
        secretName: collector
      key:
        key: tls.key
        secretName: collector
  pipelines:
  - outputRefs:
    - default-elasticsearch
  - inputRefs:
    - application
    - infrastructure

注記

この例では、アプリケーションログは app-write ではなく application-write alias/index に書き込まれます。

2.3.10. Red Hat Managed LokiStack

Red Hat Managed LokiStack への v5.9 転送

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: lokistack
    lokistack:
      name: lokistack-dev

Red Hat Managed LokiStack への v6.0 転送

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: lokistack-dev
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - outputRefs:
    - default-lokistack
  - inputRefs:
    - application
    - infrastructure

2.3.11. フィルターおよびパイプライン設定

パイプライン設定は、出力先への入力ソースのルーティングのみを定義するようになり、必要な変換はフィルターとして個別に設定されるようになりました。本リリースのパイプラインのすべての属性が、以前のリリースのフィルターに変換されました。個々のフィルターは フィルター 仕様で定義され、パイプラインから参照されます。

Filters

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
spec:
  pipelines:
   - name: application-logs
     parse: json
     labels:
       foo: bar
     detectMultilineErrors: true

フィルターの設定。

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
spec:
  filters:
  - name: detectexception
    type: detectMultilineException
  - name: parse-json
    type: parse
  - name: labels
    type: openShiftLabels
    openShiftLabels:
      foo: bar
  pipelines:
  - name: application-logs
    filterRefs:
    - detectexception
    - labels
    - parse-json

2.3.12. 検証とステータス

ほとんどの検証は、リソースが作成または更新されたときに実施され、フィードバックが即座に提供されます。これは、以前のリリース を参照してください。ここでは、検証が作成後に発生し、リソースのステータスを検査する必要があります。一部の検証は、作成時または更新時に検証できない場合に、作成後に引き続き実行されます。

Operator がログコレクター(Authorizeed、Valid、Ready)をデプロイする前に、ClusterLogForwarder.observability.openshift.io のインスタンスは次の条件を満たす必要があります。以下の条件の例を以下に示します。

.status.conditions

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
status:
  conditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: 'permitted to collect log types: [application]'
    reason: ClusterRolesExist
    status: "True"
    type: observability.openshift.io/Authorized
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/Valid
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ReconciliationComplete
    status: "True"
    type: Ready
  filterConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "detectexception" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-detectexception
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "parse-json" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-parse-json
  inputConditions:
  - lastTransitionTime: "2024-09-13T12:23:03Z"
    message: input "application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidInput-application1
  outputConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: output "default-lokistack-application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidOutput-default-lokistack-application1
  pipelineConditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: pipeline "default-before" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidPipeline-default-before

注記

満たされ、適用可能なステータスの値が True である。True 以外のステータスの条件は、理由と問題を説明するメッセージを提供します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.