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

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

Logging v6.0 は以前のリリースからの大幅なアップグレードであり、Cluster Logging の長年の目標のいくつかを達成しています。

  • ロギングコンポーネント (collectors、storage、visualization など) を管理するための個別の 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 explain は、特定のオブジェクトに関連するすべてのフィールドの詳細な説明を提供します。これには、Pod やサービスなどの標準リソースだけでなく、ステートフルセットや Operator によって定義されたカスタムリソースなどのより複雑なエンティティーも含まれます。

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

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

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

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

2.3.1.2. 階層構造

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

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

$ 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

これは、整数値を使用して 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. ログのストレージ

このリリースで利用できる唯一のマネージドログストレージソリューションは、loki-operator によって管理される Lokistack です。以前は Managed Elasticsearch オファリングの優先される代替手段として利用可能だったこのソリューションは、デプロイメントプロセスで変更されないままとなります。

重要

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

  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. 管理、リソース割り当て、ワークロードのスケジュール

管理状態 (マネージド、マネージド以外など)、リソース要求と制限、toleration、およびノード選択の設定が、新しい 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 仕様のオプション部分です。管理者は引き続き、application、infrastructure、audit の定義済み値を使用して、これらのソースを収集できます。

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

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

5.9 namespace とコンテナーの包含と除外を含むアプリケーション入力

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

6.0 namespace とコンテナーの包含と除外を含むアプリケーション入力

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

注記

application、infrastructure、audit は予約語であり、入力を定義する際は名前として使用できません。

2.3.6.2. Input Receiver

Input Receiver への変更は次のとおりです。

  • レシーバーレベルでのタイプの明示的な設定。
  • ポート設定がレシーバーレベルに移動されました。

5.9 Input Receiver

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 Input Receiver

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 と認可設定をアップグレードするには、管理者は既存のシークレットを引き続き使用するために、以前に認識されたキーを理解する必要があります。次のセクションの例では、ClusterLogForwarder シークレットを設定して、既存の Red Hat 管理のログストレージソリューションに転送する方法を詳しく説明します。

2.3.9. Red Hat Managed Elasticsearch

v5.9 Red Hat Managed Elasticsearch への転送

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

v6.0 Red Hat Managed Elasticsearch への転送

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 エイリアス/インデックスに書き込まれます。

2.3.10. Red Hat Managed LokiStack

v5.9 Red Hat Managed LokiStack への転送

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

v6.0 Red Hat Managed LokiStack への転送

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 仕様で定義され、パイプラインによって参照されます。

5.9 Filters

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

6.0 Filter の設定

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 がログコレクターをデプロイする前に、ClusterLogForwarder.observability.openshift.io のインスタンスが、Authorized、Valid、Ready の条件を満たしている必要があります。これらの条件の例は次のとおりです。

6.0 ステータス条件

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.