9.4. ログ転送の設定

手順

1. Google サービスアカウントキー を使用してシークレットを作成します。

   $ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>

2. 以下のテンプレートを使用して、ClusterLogForwarder カスタムリソース YAML を作成します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
       - name: gcp-1
         type: googleCloudLogging
         secret:
           name: gcp-secret
         googleCloudLogging:
           projectId : "openshift-gce-devel" 4
           logId : "app-gcp" 5
     pipelines:
       - name: test-app
         inputRefs: 6
           - application
         outputRefs:
           - gcp-1

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   ログを保存する GCP リソース階層 の場所に応じて、projectId、folderId、organizationId、または billingAccountId フィールドとそれに対応する値を設定します。

   5

   Log Entry の logName フィールドに追加する値を設定します。

   6

   パイプラインを使用して転送するログタイプ (application、infrastructure、または audit) を指定します。

手順

1. Base64 でエンコードされた Splunk HEC トークンを使用してシークレットを作成します。

   $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>

2. 以下のテンプレートを使用して、ClusterLogForwarder カスタムリソース (CR) を作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
       - name: splunk-receiver 4
         secret:
           name: vector-splunk-secret 5
         type: splunk 6
         url: <http://your.splunk.hec.url:8088> 7
     pipelines: 8
       - inputRefs:
           - application
           - infrastructure
         name: 9
         outputRefs:
           - splunk-receiver 10

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   HEC トークンが含まれるシークレットの名前を指定します。

   6

   出力タイプを splunk として指定します。

   7

   Splunk HEC の URL (ポートを含む) を指定します。

   8

   パイプラインを使用して転送するログタイプ (application、infrastructure、または audit) を指定します。

   9

   オプション: パイプラインの名前を指定します。

   10

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

手順

1. ClusterLogForwarder CR を定義する YAML ファイルを作成または編集します。

   ClusterLogForwarder CR の例

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     inputs: 7
      - name: my-app-logs
        application:
           namespaces:
           - my-project 8
     pipelines:
      - name: forward-to-fluentd-insecure 9
        inputRefs: 10
        - my-app-logs
        outputRefs: 11
        - fluentd-server-insecure
        labels:
          project: "my-project" 12
      - name: forward-to-fluentd-secure 13
        inputRefs:
        - application 14
        - audit
        - infrastructure
        outputRefs:
        - fluentd-server-secure
        - default
        labels:
          clusterId: "C1234"

   1

   ClusterLogForwarder CR の名前は instance である必要があります。

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前。

   4

   出力タイプ: elasticsearch、fluentdForward、syslog、または kafka。

   5

   有効な絶対 URL としての外部ログアグリゲーターの URL とポート。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   tls 接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、 tls.crt、 tls.key、 および ca-bundle.crt キーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   7

   指定されたプロジェクトからアプリケーションログをフィルターするための入力の設定。

   8

   namespace が指定されていない場合、ログはすべての namespace から収集されます。

   9

   パイプライン設定は、名前付き入力から名前付き出力にログを送信します。この例では、forward-to-fluentd-insecure という名前のパイプラインは、my-app-logs という名前の入力から fluentd-server-insecure という名前の出力にログを転送します。

   10

   入力のリスト。

   11

   使用する出力の名前。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   ログを他のログアグリゲーターに送信するためのパイプラインの設定。

   • オプション: パイプラインの名前を指定します。
   • パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。
   • このパイプラインでログを転送する時に使用する出力の名前を指定します。
   • オプション: デフォルトのログストアにログを転送するための default 出力を指定します。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   14

   この設定を使用すると、すべての namespace からのアプリケーションログが収集されることに注意してください。

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

   $ oc apply -f <filename>.yaml

手順

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。ファイルで、以下の例が示すように inputs[].name.application.selector.matchLabels の下で単純な等価ベース (Equality-based) のセレクターを使用して Pod ラベルを指定します。

   ClusterLogForwarder CR YAML ファイルのサンプル

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     pipelines:
       - inputRefs: [ myAppLogData ] 3
         outputRefs: [ default ] 4
     inputs: 5
       - name: myAppLogData
         application:
           selector:
             matchLabels: 6
               environment: production
               app: nginx
           namespaces: 7
           - app1
           - app2
     outputs: 8
       - <output_name>
       ...

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   inputs[].name から 1 つ以上のコンマ区切りの値を指定します。

   4

   outputs[] から 1 つ以上のコンマ区切りの値を指定します。

   5

   Pod ラベルの一意のセットを持つ各アプリケーションの一意の inputs[].name を定義します。

   6

   収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。

   7

   オプション: namespace を 1 つ以上指定します。

   8

   ログデータを転送する 1 つ以上の出力を指定します。

2. オプション: ログデータの収集を特定の namespace に制限するには、前述の例のように inputs[].name.application.namespaces を使用します。

3. オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。

   1. Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の inputs[].name セクションを作成します。
   2. このアプリケーションの Pod ラベルに一致するように、selectors を更新します。

   3. 新規の inputs[].name 値を inputRefs に追加します。以下に例を示します。

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

4. CR オブジェクトを作成します。

   $ oc create -f <file-name>.yaml

手順

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
     - name: loki-insecure 4
       type: "loki" 5
       url: http://loki.insecure.com:3100 6
       loki:
         tenantKey: kubernetes.namespace_name
         labelKeys:
         - kubernetes.labels.foo
     - name: loki-secure 7
       type: "loki"
       url: https://loki.secure.com:3100
       secret:
         name: loki-secret 8
       loki:
         tenantKey: kubernetes.namespace_name 9
         labelKeys:
         - kubernetes.labels.foo 10
     pipelines:
     - name: application-logs 11
       inputRefs:  12
       - application
       - audit
       outputRefs: 13
       - loki-secure

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   タイプを loki として指定します。

   6

   Loki システムの URL およびポートを有効な絶対 URL として指定します。http (セキュアでない) プロトコルまたは https (セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。HTTP(S) 通信用の Loki のデフォルトポートは 3100 です。

   7

   セキュアな接続では、シークレット を指定して、認証する https または http URL を指定できます。

   8

   https 接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。それ以外の場合、http および https 接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。

   9

   オプション: メタデータキーフィールドを指定して、Loki の TenantID フィールドの値を生成します。たとえば、tenantKey: kubernetes.namespace_name を設定すると、Kubernetes namespace の名前を Loki のテナント ID の値として使用します。他にどのログレコードフィールドを指定できるかを確認するには、以下の Additional resources セクションの Log Record Fields リンクを参照してください。

   10

   オプション: デフォルトの Loki ラベルを置き換えるメタデータフィールドキーのリストを指定します。loki ラベル名は、正規表現 [a-zA-Z_:][a-zA-Z0-9_:]* と一致する必要があります。ラベル名を形成するため、メタデータキーの無効な文字は _ に置き換えられます。たとえば、kubernetes.labels.foo メタデータキーは、Loki ラベル kubernetes_labels_foo になります。labelKeys を設定しないと、デフォルト値は [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host] です。Loki で指定可能なラベルのサイズと数に制限があるため、ラベルのセットを小さくします。Configuring Loki, limits_config を参照してください。クエリーフィルターを使用して、ログレコードフィールドに基づいてクエリーを実行できます。

   11

   オプション: パイプラインの名前を指定します。

   12

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   13

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

   注記

   Loki ではログストリームを正しくタイムスタンプで順序付ける必要があるため、labelKeys には指定しなくても kubernetes_host ラベルセットが常に含まれます。このラベルセットが含まれることで、各ストリームが 1 つのホストから発信されるので、ホストのクロック間の誤差が原因でタイムスタンプの順番が乱れないようになります。

2. 次のコマンドを実行して、ClusterLogForwarder CR オブジェクトを適用します。

   $ oc apply -f <filename>.yaml

手順

1. ClusterLogForwarder CR を定義する YAML ファイルを作成または編集します。

   ClusterLogForwarder CR の例

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
      - name: elasticsearch-example 4
        type: elasticsearch 5
        elasticsearch:
          version: 8 6
        url: http://elasticsearch.example.com:9200 7
        secret:
          name: es-secret 8
     pipelines:
      - name: application-logs 9
        inputRefs: 10
        - application
        - audit
        outputRefs:
        - elasticsearch-example 11
        - default 12
        labels:
          myLabel: "myValue" 13
   # ...

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   elasticsearch タイプを指定します。

   6

   Elasticsearch バージョンを指定します。これは 6、7、または 8 のいずれかになります。

   7

   外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。http (セキュアでない) プロトコルまたは https (セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   8

   https 接頭辞の場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定します。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。それ以外の場合、http および https 接頭辞の場合は、ユーザー名とパスワードを含むシークレットを指定できます。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。詳細は、「例: ユーザー名とパスワードを含むシークレットの設定」を参照してください。

   9

   オプション: パイプラインの名前を指定します。

   10

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   11

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

   12

   オプション: ログを内部 Elasticsearch インスタンスに送信するために default 出力を指定します。

   13

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

2. ClusterLogForwarder CR を適用します。

   $ oc apply -f <filename>.yaml

1. 以下の例のような Secret YAML ファイルを作成します。username および password フィールドに base64 でエンコードされた値を使用します。シークレットタイプはデフォルトで opaque です。

   apiVersion: v1
   kind: Secret
   metadata:
     name: openshift-test-secret
   data:
     username: <username>
     password: <password>
   # ...

2. シークレットを作成します。

   $ oc create secret -n openshift-logging openshift-test-secret.yaml

3. ClusterLogForwarder CR にシークレットの名前を指定します。

   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     outputs:
      - name: elasticsearch
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200
        secret:
           name: openshift-test-secret
   # ...

   注記

   url フィールドの値では、接頭辞は http または https になります。

4. CR オブジェクトを適用します。

   $ oc apply -f <filename>.yaml

手順

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     pipelines:
      - name: forward-to-fluentd-secure 7
        inputRefs:  8
        - application
        - audit
        outputRefs:
        - fluentd-server-secure 9
        - default 10
        labels:
          clusterId: "C1234" 11
      - name: forward-to-fluentd-insecure 12
        inputRefs:
        - infrastructure
        outputRefs:
        - fluentd-server-insecure
        labels:
          clusterId: "C1234"

   1

   ClusterLogForwarder CR の名前は instance である必要があります。

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   fluentdForward タイプを指定します。

   5

   外部 Fluentd インスタンスの URL およびポートを有効な絶対 URL として指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   tls を接頭辞として使用している場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在する必要があり、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。

   7

   オプション: パイプラインの名前を指定します。

   8

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   9

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

   10

   オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。

   11

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   12

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

2. CR オブジェクトを作成します。

   $ oc create -f <file-name>.yaml

手順

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
      - name: rsyslog-east 4
        type: syslog 5
        syslog: 6
          facility: local0
          rfc: RFC3164
          payloadKey: message
          severity: informational
        url: 'tls://rsyslogserver.east.example.com:514' 7
        secret: 8
           name: syslog-secret
      - name: rsyslog-west
        type: syslog
        syslog:
         appName: myapp
         facility: user
         msgID: mymsg
         procID: myproc
         rfc: RFC5424
         severity: debug
        url: 'tcp://rsyslogserver.west.example.com:514'
     pipelines:
      - name: syslog-east 9
        inputRefs: 10
        - audit
        - application
        outputRefs: 11
        - rsyslog-east
        - default 12
        labels:
          secure: "true" 13
          syslog: "east"
      - name: syslog-west 14
        inputRefs:
        - infrastructure
        outputRefs:
        - rsyslog-west
        - default
        labels:
          syslog: "west"

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   syslog タイプを指定します。

   6

   オプション: 以下にリスト表示されている syslog パラメーターを指定します。

   7

   外部 syslog インスタンスの URL およびポートを指定します。udp (セキュアでない)、tcp (セキュアでない) プロトコル、または tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   8

   tls 接頭辞を使用する場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。

   9

   オプション: パイプラインの名前を指定します。

   10

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   11

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

   12

   オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。

   13

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。

   14

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

2. CR オブジェクトを作成します。

   $ oc create -f <filename>.yaml

手順

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
      - name: app-logs 4
        type: kafka 5
        url: tls://kafka.example.devlab.com:9093/app-topic 6
        secret:
          name: kafka-secret 7
      - name: infra-logs
        type: kafka
        url: tcp://kafka.devlab2.example.com:9093/infra-topic 8
      - name: audit-logs
        type: kafka
        url: tls://kafka.qelab.example.com:9093/audit-topic
        secret:
           name: kafka-secret-qe
     pipelines:
      - name: app-topic 9
        inputRefs: 10
        - application
        outputRefs: 11
        - app-logs
        labels:
          logType: "application" 12
      - name: infra-topic 13
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        labels:
          logType: "audit"

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   kafka タイプを指定します。

   6

   Kafka ブローカーの URL およびポートを有効な絶対 URL として指定し、オプションで特定のトピックで指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   7

   tls を接頭辞として使用している場合は、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットには、それが表す証明書を指す ca-bundle.crt 鍵が含まれている必要があります。レガシー実装では、シークレットは openshift-logging プロジェクトに存在する必要があります。

   8

   オプション: 非セキュアな出力を送信するには、URL の前に tcp の接頭辞を使用します。また、この出力の secret キーとその name を省略します。

   9

   オプション: パイプラインの名前を指定します。

   10

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   11

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

2. オプション: 単一の出力を複数の Kafka ブローカーに転送するには、次の例に示すように Kafka ブローカーの配列を指定します。

   # ...
   spec:
     outputs:
     - name: app-logs
       type: kafka
       secret:
         name: kafka-secret-dev
       kafka:  1
         brokers: 2
           - tls://kafka-broker1.example.com:9093/
           - tls://kafka-broker2.example.com:9093/
         topic: app-topic 3
   # ...

   1

   brokers および topic キーを持つ kafka キーを指定します。

   2

   brokers キーを指定して、1 つ以上のブローカーを指定します。

   3

   トピック キーを使用して、ログを受信するターゲットトピックを指定します。

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

   $ oc apply -f <filename>.yaml

手順

1. aws_access_key_id および aws_secret_access_key フィールドを使用する Secret YAML ファイルを作成し、base64 でエンコードされた AWS 認証情報を指定します。以下に例を示します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: cw-secret
     namespace: openshift-logging
   data:
     aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
     aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=

2. シークレットを作成します。以下に例を示します。

   $ oc apply -f cw-secret.yaml

3. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。このファイルに、シークレットの名前を指定します。以下に例を示します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
      - name: cw 4
        type: cloudwatch 5
        cloudwatch:
          groupBy: logType 6
          groupPrefix: <group prefix> 7
          region: us-east-2 8
        secret:
           name: cw-secret 9
     pipelines:
       - name: infra-logs 10
         inputRefs: 11
           - infrastructure
           - audit
           - application
         outputRefs:
           - cw 12

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   サービスアカウントの名前。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   cloudwatch タイプを指定します。

   6

   オプション: ログをグループ化する方法を指定します。

   • logType は、ログタイプごとにロググループを作成します。
   • namespaceName は、アプリケーションの namespace ごとにロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。
   • namespaceUUID は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。

   7

   オプション: ロググループの名前に含まれるデフォルトの infrastructureName 接頭辞を置き換える文字列を指定します。

   8

   AWS リージョンを指定します。

   9

   AWS 認証情報が含まれるシークレットの名前を指定します。

   10

   オプション: パイプラインの名前を指定します。

   11

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   12

   このパイプラインでログを転送する時に使用する出力の名前を指定します。

4. CR オブジェクトを作成します。

   $ oc create -f <file-name>.yaml

手順

1. 以下のテンプレートを使用して、CredentialsRequest カスタムリソース YAML を作成します。

   CloudWatch クレデンシャルリクエストのテンプレート

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <your_role_name>-credrequest
     namespace: openshift-cloud-credential-operator
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
         - action:
             - logs:PutLogEvents
             - logs:CreateLogGroup
             - logs:PutRetentionPolicy
             - logs:CreateLogStream
             - logs:DescribeLogGroups
             - logs:DescribeLogStreams
           effect: Allow
           resource: arn:aws:logs:*:*:*
     secretRef:
       name: <your_role_name>
       namespace: openshift-logging
     serviceAccountNames:
       - logcollector

2. ccoctl コマンドを使用して、CredentialsRequest CR を使用して AWS のロールを作成します。CredentialsRequestオブジェクトでは、この ccoctl コマンドを使用すると、特定の OIDC アイデンティティープロバイダーに紐付けされたトラストポリシーと、CloudWatch リソースでの操作実行パーミッションを付与するパーミッションポリシーを指定して IAM ロールを作成します。このコマンドは、/<path_to_ccoctl_output_dir>/manifests/openshift-logging-<your_role_name>-credentials.yaml に YAML 設定ファイルも作成します。このシークレットファイルには、AWS IAM ID プロバイダーでの認証中に使用される role_arn キー/値が含まれています。

   $ ccoctl aws create-iam-roles \
   --name=<name> \
   --region=<aws_region> \
   --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
   --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com 1

   1

   <name> は、クラウドリソースのタグ付けに使用される名前であり、STS クラスターのインストール中に使用される名前と一致する必要があります。

3. 作成したシークレットを適用します。

   $ oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml

4. ClusterLogForwarder カスタムリソースを作成または編集します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: clf-collector 3
     outputs:
      - name: cw 4
        type: cloudwatch 5
        cloudwatch:
          groupBy: logType 6
          groupPrefix: <group prefix> 7
          region: us-east-2 8
        secret:
           name: <your_secret_name> 9
     pipelines:
       - name: to-cloudwatch 10
         inputRefs: 11
           - infrastructure
           - audit
           - application
         outputRefs:
           - cw 12

   1

   レガシー実装では、CR 名は instance である必要があります。マルチログフォワーダー実装では、任意の名前を使用できます。

   2

   レガシー実装では、CR namespace は openshift-logging である必要があります。マルチログフォワーダー実装では、任意の namespace を使用できます。

   3

   clf-collector サービスアカウントを指定します。サービスアカウントは、ログフォワーダーが openshift-logging namespace にデプロイされていない場合、マルチログフォワーダーの実装でのみ必要です。

   4

   出力の名前を指定します。

   5

   cloudwatch タイプを指定します。

   6

   オプション: ログをグループ化する方法を指定します。

   • logType は、ログタイプごとにロググループを作成します。
   • namespaceName は、アプリケーションの namespace ごとにロググループを作成します。インフラストラクチャーおよび監査ログは影響を受けず、logType によってグループ化されたままになります。
   • namespaceUUID は、アプリケーション namespace UUID ごとに新しいロググループを作成します。また、インフラストラクチャーおよび監査ログ用の個別のロググループも作成します。

   7

   オプション: ロググループの名前に含まれるデフォルトの infrastructureName 接頭辞を置き換える文字列を指定します。

   8

   AWS リージョンを指定します。

   9

   AWS 認証情報が含まれるシークレットの名前を指定します。

   10

   オプション: パイプラインの名前を指定します。

   11

   パイプラインを使用して転送するログタイプ (application、infrastructure または audit) を指定します。

   12

   このパイプラインでログを転送する時に使用する出力の名前を指定します。