9.4. 配置日志转发

流程

1. 使用 Google 服务帐户密钥创建 secret。

   $ 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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   根据您要将日志存储在 GCP 资源层次结构中的位置，设置 projectId, folderId, organizationId, 或 billingAccountId 的项及其相应的值。

   5

   将值设为添加到 Log Entry 的 logName 字段的值。

   6

   使用管道指定要转发的日志类型：application, infrastructure, 或 audit。

流程

1. 使用您的 Base64 编码的 Splunk HEC 令牌创建 secret。

   $ 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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定包含 HEC 令牌的 secret 名称。

   6

   将输出类型指定为 mvapich。

   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 的命名空间必须是 openshift-logging。

   3

   输出的名称。

   4

   输出类型：elasticsearch, fluentdForward, syslog, 或 kafka。

   5

   外部日志聚合器的 URL 和端口作为有效的绝对 URL。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，并具有每个指向它们所代表证书的 tls.crt、tls.key 和 ca-bundle.crt 密钥。

   7

   用于过滤指定项目的应用程序日志的输入配置。

   8

   如果没有指定命名空间，则会从所有命名空间收集日志。

   9

   管道配置将来自一个命名输入的日志定向到一个命名的输出。在本例中，名为 forward-to-fluentd-insecure 的管道将日志从一个名为 my-app-logs 的输入转发到名为 fluentd-server-insecure 的输出。

   10

   输入列表。

   11

   要使用的输出名称。

   12

   可选：字符串。要添加到日志中的一个或多个标签。

   13

   管道配置，将日志发送到其他日志聚合器。

   • 可选：指定管道的名称。
   • 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
   • 指定使用此管道转发日志时使用的输出名称。
   • 可选：指定将日志转发到默认日志存储的默认输出。
   • 可选：字符串。要添加到日志中的一个或多个标签。

   14

   请注意，使用此配置时，会从所有命名空间收集应用程序日志。

2. 运行以下命令来应用 ClusterLogForwarder CR：

   $ oc apply -f <filename>.yaml

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件。在文件中，使用 inputs[].name.application.selector.matchLabels 下的简单基于平等的选择器来指定 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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   指定来自 inputs[].name 的一个或多个以逗号分隔的值。

   4

   指定来自 outputs[] 的一个或多个以逗号分隔的值。

   5

   为具有一组唯一 pod 标签的每个应用程序定义唯一的 inputs[].name。

   6

   指定您要收集的日志数据的 pod 标签的键值对。您必须指定一个键和值，而不仅仅是一个键。要被选择，pod 必须与所有键值对匹配。

   7

   可选：指定一个或多个命名空间。

   8

   指定要将日志数据转发到的一个或多个输出。

2. 可选： 要将日志数据收集限制为特定的命名空间，请使用 inputs[].name.application.namespaces，如上例中所示。

3. 可选： 您可以从具有不同 pod 标签的额外应用程序向同一管道发送日志数据。

   1. 对于 pod 标签的每个唯一组合，创建一个类似于显示的 inputs[].name 部分。
   2. 更新选择器（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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   将类型指定为 "loki"。

   6

   将 Loki 系统的 URL 和端口指定为有效的绝对 URL。您可以使用 http （不安全）或 https （安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。Loki 用于 HTTP(S) 通讯的默认端口为 3100。

   7

   对于安全连接，您可以通过指定 secret 来指定您进行身份验证的 https 或 http URL。

   8

   对于 https 前缀，请指定 TLS 通信端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键，它指向它所代表的证书。否则，对于 http 和 https 前缀，您可以指定一个包含用户名和密码的 secret。在旧的实现中，secret 必须存在于 openshift-logging 项目中。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。

   9

   可选：指定一个 metadata key 字段，为 Loki 中的 TenantID 字段生成值。例如，设置 tenantKey: kubernetes.namespace_name 使用 Kubernetes 命名空间的名称作为 Loki 中的租户 ID 的值。要查看您可以指定的其他日志记录字段，请查看以下"Additional resources"部分中的"Log Record Fields"链接。

   10

   可选：指定一个 metadata 字段键列表来替换默认的 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 会限制允许标签的大小和数量。请参阅配置 Loki、limit_config。您仍然可以使用查询过滤器基于任何日志记录字段进行查询。

   11

   可选：指定管道的名称。

   12

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   13

   指定使用此管道转发日志时使用的输出名称。

   注意

   由于 Loki 要求按时间戳正确排序日志流，labelKeys 始终包含 kubernetes_host 标签，即使您没有指定它。此包含确保每个流源自单一主机，这样可防止因为不同主机上的时钟差异而导致时间戳出现问题。

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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定 elasticsearch 类型。

   6

   指定 Elasticsearch 版本。这可以是 6、7 或 8。

   7

   指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用 http （不安全）或 https （安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   8

   对于 https 前缀，请指定 TLS 通信端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键，它指向它所代表的证书。否则，对于 http 和 https 前缀，您可以指定一个包含用户名和密码的 secret。在旧的实现中，secret 必须存在于 openshift-logging 项目中。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。

   9

   可选：指定管道的名称。

   10

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   11

   指定使用此管道转发日志时使用的输出名称。

   12

   可选：指定将日志发送到内部 Elasticsearch 实例的 default 输出。

   13

   可选：字符串。要添加到日志中的一个或多个标签。

2. 应用 ClusterLogForwarder CR：

   $ oc apply -f <filename>.yaml

1. 创建类似于以下示例的 Secret YAML 文件。将 base64 编码的值用于 username 和 password 字段。secret 类型默认为 opaque。

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

2. 创建 secret：

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

3. 在 ClusterLogForwarder CR 中指定 secret 的名称：

   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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 fluentdForward 类型。

   5

   指定外部 Fluentd 实例的 URL 和端口作为有效的绝对 URL。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须包含指向它所代表证书的 ca-bundle.crt 键。

   7

   可选：指定管道的名称。

   8

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   9

   指定使用此管道转发日志时使用的输出名称。

   10

   可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定 syslog 类型。

   6

   可选：指定 syslog 参数，如下所列。

   7

   指定外部 syslog 实例的 URL 和端口。您可以使用 udp （不安全）、tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   8

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键，它指向它所代表的证书。在旧的实现中，secret 必须存在于 openshift-logging 项目中。

   9

   可选：指定管道的名称。

   10

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   11

   指定使用此管道转发日志时使用的输出名称。

   12

   可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。

   13

   可选：字符串。要添加到日志中的一个或多个标签。对值加引号（如 "true"），以便它们被识别为字符串值，而不是作为布尔值。

   14

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定 kafka 类型。

   6

   将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL，也可以同时指定特定标题。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   7

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键，它指向它所代表的证书。在旧的实现中，secret 必须存在于 openshift-logging 项目中。

   8

   可选： 要发送不安全的输出，在 URL 前面使用 tcp 前缀。另外，省略此输出中的 secret 键及其 name。

   9

   可选：指定管道的名称。

   10

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   11

   指定使用此管道转发日志时使用的输出名称。

   12

   可选：字符串。要添加到日志中的一个或多个标签。

   13

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 键指定一个或多个代理的数组。

   3

   使用 topic 键指定要接收日志的目标主题。

3. 运行以下命令来应用 ClusterLogForwarder CR：

   $ oc apply -f <filename>.yaml

流程

1. 创建一个 Secret YAML 文件，它使用 aws_access_key_id 和 aws_secret_access_key 字段来指定您的 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. 创建 secret.例如：

   $ oc apply -f cw-secret.yaml

3. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件。在文件中，指定 secret 的名称。例如：

   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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定 cloudwatch 类型。

   6

   可选：指定如何对日志进行分组：

   • logType 为每个日志类型创建日志组。
   • namespaceName 为每个应用程序命名空间创建一个日志组。它还会为基础架构和审计日志创建单独的日志组。
   • namespaceUUID 为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。

   7

   可选：指定一个字符串来替换日志组名称中的默认 infrastructureName 前缀。

   8

   指定 AWS 区域。

   9

   指定包含 AWS 凭证的 secret 名称。

   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 命令会创建一个带有信任策略的 IAM 角色，该角色与指定的 OIDC 身份提供程序相关联，以及一个授予对 CloudWatch 资源执行操作的权限策略。此命令在 /<path_to_ccoctl_output_dir>/manifests/openshift-logging-<your_role_name>-credentials.yaml 中创建了一个 YAML 配置文件。此 secret 文件包含与 AWS IAM 身份提供程序进行身份验证时使用的 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. 应用创建的 secret：

   $ 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 命名空间必须是 openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。

   3

   指定 clf-collector 服务帐户。如果没有在 openshift-logging 命名空间中部署日志转发器，则只有多日志转发器实现中才需要服务帐户。

   4

   指定输出的名称。

   5

   指定 cloudwatch 类型。

   6

   可选：指定如何对日志进行分组：

   • logType 为每个日志类型创建日志组。
   • namespaceName 为每个应用程序命名空间创建一个日志组。基础架构和审计日志不受影响，剩余的日志按照 logType 分组。
   • namespaceUUID 为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。

   7

   可选：指定一个字符串来替换日志组名称中的默认 infrastructureName 前缀。

   8

   指定 AWS 区域。

   9

   指定包含 AWS 凭证的 secret 名称。

   10

   可选：指定管道的名称。

   11

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   12

   指定使用此管道转发日志时使用的输出名称。