OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

配置日志转发

编辑

在日志部署中，容器和基础架构日志默认情况下会转发到在ClusterLogging自定义资源 (CR) 中定义的内部日志存储。

审计日志默认情况下不会转发到内部日志存储，因为这无法提供安全的存储。您有责任确保将审计日志转发到的系统符合您的组织和政府法规，并得到妥善保护。

如果此默认配置满足您的需求，则无需配置ClusterLogForwarder CR。如果存在ClusterLogForwarder CR，则除非定义包含default输出的管道，否则不会将日志转发到内部日志存储。

关于将日志转发到第三方系统

要将日志发送到 Red Hat OpenShift Service on AWS 集群内部和外部的特定端点，请在ClusterLogForwarder自定义资源 (CR) 中指定输出和管道的组合。您还可以使用输入将与特定项目关联的应用程序日志转发到端点。身份验证由 Kubernetes 密钥对象提供。

管道

定义从一种日志类型到一个或多个输出的简单路由，或者要发送哪些日志。日志类型如下所示：

  • application。集群中用户应用程序生成的容器日志，不包括基础架构容器应用程序。

  • infrastructure。来自在openshift*、kube*或default项目中运行的 Pod 的容器日志以及从节点文件系统获取的日志。

  • audit。由节点审计系统auditd、Kubernetes API 服务器、OpenShift API 服务器和 OVN 网络生成的审计日志。

您可以使用管道中的key:value对向出站日志消息添加标签。例如，您可以向转发到其他数据中心的邮件添加标签，或按类型标记日志。添加到对象的标签也会与日志消息一起转发。

输入

将与特定项目关联的应用程序日志转发到管道。

在管道中，您可以使用inputRef参数定义要转发的日志类型，并使用outputRef参数定义将日志转发到的位置。

密钥

包含机密数据（例如用户凭据）的key:value map。

请注意以下几点：

  • 如果您没有为日志类型定义管道，则未定义类型的日志将被丢弃。例如，如果您为application和audit类型指定了管道，但没有为infrastructure类型指定管道，则infrastructure日志将被丢弃。

  • 您可以在ClusterLogForwarder自定义资源 (CR) 中使用多种类型的输出，将日志发送到支持不同协议的服务器。

以下示例将审计日志转发到安全的外部 Elasticsearch 实例，将基础架构日志转发到不安全的外部 Elasticsearch 实例，将应用程序日志转发到 Kafka 代理，并将my-apps-logs项目的应用程序日志转发到内部 Elasticsearch 实例。

日志转发输出和管道的示例
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-secure (4)
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure (5)
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app (6)
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: (7)
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs (8)
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     labels:
       secure: "true" (9)
       datacenter: "east"
   - name: infrastructure-logs (10)
     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app (11)
     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs: (12)
      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"
1 在旧版实现中，CR 名称必须为instance。在多日志转发器实现中，您可以使用任何名称。
2 在旧版实现中，CR 命名空间必须为openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。
3 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
4 使用包含安全 URL 的密钥的安全 Elasticsearch 输出的配置。

  • 描述输出的名称。

  • 输出类型：elasticsearch。

  • Elasticsearch 实例的安全 URL 和端口，作为有效的绝对 URL，包括前缀。

  • 端点用于 TLS 通信所需的密钥。密钥必须存在于openshift-logging项目中。
5 不安全 Elasticsearch 输出的配置

  • 描述输出的名称。

  • 输出类型：elasticsearch。

  • Elasticsearch 实例的不安全 URL 和端口，作为有效的绝对 URL，包括前缀。
6 使用客户端身份验证 TLS 通信通过安全 URL 进行 Kafka 输出的配置

  • 描述输出的名称。

  • 输出类型：kafka。

  • 指定 Kafka 代理的 URL 和端口，作为有效的绝对 URL，包括前缀。
7 用于过滤my-project命名空间中的应用程序日志的输入的配置
8 用于将审计日志发送到安全的外部 Elasticsearch 实例的管道的配置

  • 描述管道的名称。

  • inputRefs是日志类型，在此示例中为audit。

  • outputRefs是要使用的输出的名称，在此示例中为elasticsearch-secure（转发到安全的 Elasticsearch 实例）和default（转发到内部 Elasticsearch 实例）。

  • 可选：要添加到日志的标签。
9 可选：字符串。要添加到日志的一个或多个标签。引用诸如“true”之类的值，以便它们被识别为字符串值，而不是布尔值。
10 用于将基础架构日志发送到不安全的外部 Elasticsearch 实例的管道的配置。
11 用于将my-project项目的日志发送到内部 Elasticsearch 实例的管道的配置。

  • 描述管道的名称。

  • inputRefs是特定的输入：my-app-logs。

  • outputRefs为default。

  • 可选：字符串。要添加到日志的一个或多个标签。
12 用于将日志发送到 Kafka 代理的管道的配置，没有管道名称

  • inputRefs是日志类型，在此示例中为application。

  • outputRefs是要使用的输出的名称。

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

外部日志聚合器不可用时的 Fluentd 日志处理

如果外部日志聚合器不可用且无法接收日志，Fluentd 将继续收集日志并将它们存储在缓冲区中。当日志聚合器可用时，日志转发将恢复，包括缓冲的日志。如果缓冲区完全填满，Fluentd 将停止收集日志。Red Hat OpenShift Service on AWS 将轮换日志并将其删除。您无法调整缓冲区大小或向 Fluentd daemonset 或 Pod 添加持久卷声明 (PVC)。

支持的授权密钥

此处提供了常见的密钥类型。某些输出类型支持其他专用密钥，这些密钥已在特定于输出的配置字段中进行了记录。所有密钥都是可选的。通过设置相关的密钥来启用所需的安全性功能。您有责任创建和维护外部目标可能需要的任何其他配置，例如密钥和机密、服务帐户、端口打开或全局代理配置。OpenShift Logging 不会尝试验证授权组合之间的不匹配。

传输层安全性 (TLS)

使用 TLS URL（http://... 或 ssl://...）无需密钥即可启用基本的 TLS 服务器端身份验证。通过包含密钥并设置以下可选字段，可以启用其他 TLS 功能。

  • passphrase：（字符串）解码编码的 TLS 私钥的密码。需要 tls.key。

  • ca-bundle.crt：（字符串）服务器身份验证的客户 CA 文件名。

用户名和密码

  • username：（字符串）身份验证用户名。需要 password。

  • password：（字符串）身份验证密码。需要 username。

简单身份验证安全层 (SASL)

  • sasl.enable（布尔值）显式启用或禁用 SASL。如果缺失，则在设置任何其他 sasl. 密钥时自动启用 SASL。

  • sasl.mechanisms：（数组）允许的 SASL 机制名称列表。如果缺失或为空，则使用系统默认值。

  • sasl.allow-insecure：（布尔值）允许发送明文密码的机制。默认为 false。

编辑

创建密钥

您可以使用以下命令在包含证书和密钥文件的目录中创建密钥

$ oc create secret generic -n <namespace> <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>

建议使用通用或不透明密钥以获得最佳结果。
编辑

创建日志转发器

要创建日志转发器，您必须创建一个ClusterLogForwarder CR，该 CR 指定服务帐户可以收集的日志输入类型。您还可以指定可以将日志转发到的输出。如果您使用的是多日志转发器功能，则还必须在ClusterLogForwarder CR 中引用服务帐户。

如果您在集群上使用多日志转发器功能，则可以在任何命名空间中使用任何名称创建ClusterLogForwarder 自定义资源 (CR)。如果您使用的是旧版实现，则ClusterLogForwarder CR 必须命名为instance，并且必须在openshift-logging命名空间中创建。

您需要创建ClusterLogForwarder CR 的命名空间的管理员权限。
ClusterLogForwarder 资源示例
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> (1)
  namespace: <log_forwarder_namespace> (2)
spec:
  serviceAccountName: <service_account_name> (3)
  pipelines:
   - inputRefs:
     - <log_type> (4)
     outputRefs:
     - <output_name> (5)
  outputs:
  - name: <output_name> (6)
    type: <output_type> (5)
    url: <log_output_url> (7)
# ...
1 在旧版实现中，CR 名称必须为instance。在多日志转发器实现中，您可以使用任何名称。
2 在旧版实现中，CR 命名空间必须为openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。
3 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
4 收集的日志类型。此字段的值可以是审计日志的audit、应用程序日志的application、基础设施日志的infrastructure，或为您的应用程序定义的命名输入。
5 要将日志转发到的输出类型。此字段的值可以是default、loki、kafka、elasticsearch、fluentdForward、syslog 或cloudwatch。

在多日志转发器实现中不支持default输出类型。
6 要将日志转发到的输出的名称。
7 要将日志转发到的输出的 URL。
编辑

调整日志有效负载和交付

在 5.9 及更高版本的日志记录中，ClusterLogForwarder 自定义资源 (CR) 中的tuning规范提供了一种配置部署以优先考虑日志吞吐量或持久性的方法。

例如，如果您需要减少收集器重新启动时日志丢失的可能性，或者您需要收集的日志消息能够在收集器重新启动后继续存在以支持法规要求，则可以调整您的部署以优先考虑日志持久性。如果您使用的输出对可以接收的批次大小有严格限制，则可能需要调整您的部署以优先考虑日志吞吐量。

要使用此功能，您的日志记录部署必须配置为使用 Vector 收集器。使用 Fluentd 收集器时，不支持ClusterLogForwarder CR 中的tuning规范。

以下示例显示您可以修改以调整日志转发器输出的ClusterLogForwarder CR 选项

ClusterLogForwarder CR 调整选项示例
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  tuning:
    delivery: AtLeastOnce (1)
    compression: none (2)
    maxWrite: <integer> (3)
    minRetryDuration: 1s (4)
    maxRetryDuration: 1s (5)
# ...
1 指定日志转发的交付模式。

  • AtLeastOnce交付意味着，如果日志转发器崩溃或重新启动，则在崩溃之前读取但未发送到其目标的任何日志都会重新发送。崩溃后某些日志可能会重复。

  • AtMostOnce交付意味着日志转发器不会努力恢复在崩溃期间丢失的日志。此模式可提供更好的吞吐量，但可能会导致更大的日志丢失。
2 指定compression配置会导致在数据通过网络发送之前对其进行压缩。请注意，并非所有输出类型都支持压缩，如果输出不支持指定的压缩类型，则会导致错误。此配置的可能值为none（不压缩）、gzip、snappy、zlib 或zstd。如果您使用的是 Kafka 输出，则还可以使用lz4压缩。有关更多信息，请参见表“支持的压缩类型用于调整输出”。
3 指定单个发送操作到输出的最大有效负载限制。
4 指定在故障后尝试重新交付之前等待的最小持续时间。此值是一个字符串，可以指定为毫秒 (ms)、秒 (s) 或分钟 (m)。
5 指定在故障后尝试重新交付之前等待的最大持续时间。此值是一个字符串，可以指定为毫秒 (ms)、秒 (s) 或分钟 (m)。
表 1. 支持的压缩类型用于调整输出
压缩算法 Splunk Amazon Cloudwatch Elasticsearch 8 LokiStack Apache Kafka HTTP Syslog Google Cloud Microsoft Azure Monitoring

gzip

X

X

X

X

X

snappy

X

X

X

X

zlib

X

X

X

zstd

X

X

X

lz4

X

启用多行异常检测

启用容器日志的多行错误检测。

启用此功能可能会对性能产生影响，可能需要额外的计算资源或替代日志记录解决方案。

日志解析器通常会错误地将同一异常的单独行识别为单独的异常。这会导致额外的日志条目以及对跟踪信息的了解不完整或不准确。

Java 异常示例
java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

  • 要启用日志记录以检测多行异常并将它们重新组合到单个日志条目中，请确保ClusterLogForwarder 自定义资源 (CR) 包含值为true的detectMultilineErrors字段。

ClusterLogForwarder CR 示例
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true
编辑

详情

当日志消息显示为形成异常堆栈跟踪的连续序列时，它们将组合成单个统一的日志记录。第一个日志消息的内容将替换为序列中所有消息字段的连接内容。

表 2. 按收集器支持的语言
语言 Fluentd Vector

Java

✓

✓

JS

✓

✓

Ruby

✓

✓

Python

✓

✓

Golang

✓

✓

PHP

✓

✓

Dart

✓

✓

故障排除

启用后，收集器配置将包含一个新的部分，类型为：detect_exceptions

Vector 配置部分示例
[transforms.detect_exceptions_app-logs]
 type = "detect_exceptions"
 inputs = ["application"]
 languages = ["All"]
 group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"]
 expire_after_ms = 2000
 multiline_flush_interval_ms = 1000
Fluentd 配置部分示例
<label @MULTILINE_APP_LOGS>
  <match kubernetes.**>
    @type detect_exceptions
    remove_tag_prefix 'kubernetes'
    message message
    force_line_breaks true
    multiline_flush_interval .2
  </match>
</label>
编辑

将日志转发到 Splunk

除了内部默认的 Red Hat OpenShift Service on AWS 日志存储之外，您还可以将日志转发到Splunk HTTP 事件收集器 (HEC)。

不支持将此功能与 Fluentd 一起使用。
先决条件

  • Red Hat OpenShift Logging Operator 5.6 或更高版本

  • 指定vector作为收集器的ClusterLogging实例

  • Base64 编码的 Splunk HEC 令牌

步骤

  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 命名空间必须为openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。
    3 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
    4 指定输出的名称。
    5 指定包含 HEC 令牌的密钥的名称。
    6 将输出类型指定为splunk。
    7 指定 Splunk HEC 的 URL（包括端口）。
    8 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    9 可选：为管道指定名称。
    10 指定使用此管道转发日志时要使用的输出名称。
编辑

通过 HTTP 转发日志

Fluentd 和 Vector 日志收集器都支持通过 HTTP 转发日志。要启用此功能，请在 ClusterLogForwarder 自定义资源 (CR) 中将输出类型指定为 http。

步骤

  • 使用以下模板创建或编辑 ClusterLogForwarder CR

    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: httpout-app
      type: http
      url: (4)
      http:
        headers: (5)
          h1: v1
          h2: v2
        method: POST
      secret:
        name: (6)
      tls:
        insecureSkipVerify: (7)
  pipelines:
    - name:
      inputRefs:
        - application
      outputRefs:
        - httpout-app (8)
    1 在旧版实现中，CR 名称必须为instance。在多日志转发器实现中，您可以使用任何名称。
    2 在旧版实现中，CR 命名空间必须为openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。
    3 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
    4 日志的目标地址。
    5 要与日志记录一起发送的其他标头。
    6 目标凭据的密钥名称。
    7 值为 true 或 false。
    8 此值应与输出名称相同。
编辑

转发到 Azure Monitor Logs

在日志记录 5.9 及更高版本中，除了默认日志存储之外，还可以将日志转发到Azure Monitor Logs。此功能由Vector Azure Monitor Logs 接收器提供。

先决条件

  • 您熟悉如何管理和创建 ClusterLogging 自定义资源 (CR) 实例。

  • 您熟悉如何管理和创建 ClusterLogForwarder CR 实例。

  • 您了解 ClusterLogForwarder CR 规范。

  • 您对 Azure 服务有基本的了解。

  • 您已配置 Azure 帐户以访问 Azure 门户或 Azure CLI。

  • 您已获取 Azure Monitor Logs 主密钥或辅助密钥。

  • 您已确定要转发的日志类型。

要通过 HTTP 数据收集器 API 启用日志转发到 Azure Monitor Logs

使用共享密钥创建一个密钥。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key> (1)
1 必须包含用于发出请求的Log Analytics 工作区的主密钥或辅助密钥。

要获取共享密钥，可以在 Azure CLI 中使用此命令

Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”

使用与您的日志选择匹配的模板创建或编辑您的 ClusterLogForwarder CR。

转发所有日志
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id (1)
      logType: my_log_type (2)
    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor
1 Log Analytics 工作区的唯一标识符。必填字段。
2 Azure 记录类型正在提交的数据。只能包含字母、数字和下划线 (_) ，并且不能超过 100 个字符。
转发应用程序和基础设施日志
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor-app
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: application_log (1)
    secret:
      name: my-secret
  - name: azure-monitor-infra
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: infra_log #
    secret:
      name: my-secret
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor-app
    - name: infra-pipeline
      inputRefs:
      - infrastructure
      outputRefs:
      - azure-monitor-infra
1 Azure 记录类型正在提交的数据。只能包含字母、数字和下划线 (_) ，并且不能超过 100 个字符。
高级配置选项
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: my_log_type
      azureResourceId: "/subscriptions/111111111" (1)
      host: "ods.opinsights.azure.com" (2)
    secret:
       name: my-secret
  pipelines:
   - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor
1 应将数据关联到的 Azure 资源的资源 ID。可选字段。
2 专用于 Azure 区域的备用主机。可选字段。默认值为 ods.opinsights.azure.com。Azure Government 的默认值为 ods.opinsights.azure.us。
编辑

转发来自特定项目的应用程序日志

除了使用内部日志存储之外，还可以将特定项目的应用程序日志副本转发到外部日志聚合器。您还必须配置外部日志聚合器以接收来自 Red Hat OpenShift Service on AWS 的日志数据。

要配置从项目转发应用程序日志，必须创建一个 ClusterLogForwarder 自定义资源 (CR)，其中至少包含一个来自项目的输入、其他日志聚合器的可选输出以及使用这些输入和输出的管道。

先决条件

  • 您必须拥有一个已配置为使用指定的协议或格式接收日志数据的日志服务器。

步骤

  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 通信所需的密钥名称。该密钥必须存在于 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。

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

    • 可选：指定 default 输出以将日志转发到默认日志存储。

    • 可选：字符串。要添加到日志的一个或多个标签。
    14 请注意，使用此配置时，将收集来自所有命名空间的应用程序日志。

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

    $ oc apply -f <filename>.yaml
编辑

转发来自特定 Pod 的应用程序日志

作为集群管理员，您可以使用 Kubernetes Pod 标签来收集来自特定 Pod 的日志数据并将其转发到日志收集器。

假设您有一个应用程序，该应用程序由与其他 Pod 一起在各个命名空间中运行的 Pod 组成。如果这些 Pod 具有标识应用程序的标签，则可以将它们的数据收集并输出到特定的日志收集器。

要指定 Pod 标签，您可以使用一个或多个 matchLabels 键值对。如果指定多个键值对，则 Pod 必须匹配所有键值对才能被选中。

步骤

  1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件。在文件中，使用 inputs[].name.application.selector.matchLabels 下的基于简单相等的 selectors 指定 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以匹配此应用程序的 Pod 标签。

    3. 将新的inputs[].name值添加到inputRefs。例如

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

  4. 创建 CR 对象

    $ oc create -f <file-name>.yaml
其他资源
编辑

API 审计过滤器的概述

OpenShift API 服务器为每个 API 调用生成审计事件，详细说明请求、响应和请求者的身份，从而导致大量数据。API 审计过滤器使用规则来启用排除非必要事件和减少事件大小，从而促进更易于管理的审计跟踪。规则按顺序检查，在第一次匹配时停止检查。事件中包含多少数据取决于level字段的值

  • None：事件被丢弃。

  • Metadata：包含审计元数据，删除请求和响应正文。

  • Request：包含审计元数据和请求正文，删除响应正文。

  • RequestResponse：包含所有数据：元数据、请求正文和响应正文。响应正文可能非常大。例如，oc get pods -A会生成一个包含集群中每个 Pod 的 YAML 描述的响应正文。

只有在您的日志记录部署中设置了 Vector 收集器，您才能使用此功能。

在 5.8 及更高版本的日志记录中，ClusterLogForwarder自定义资源 (CR) 使用与标准Kubernetes 审计策略相同的格式，同时提供以下附加功能

通配符

用户、组、命名空间和资源的名称可以具有前导或尾随*星号字符。例如，命名空间openshift-\*匹配openshift-apiserver或openshift-authentication。资源\*/status匹配Pod/status或Deployment/status。

默认规则

策略中与任何规则都不匹配的事件将按如下方式过滤

  • 只读系统事件（例如get、list、watch）将被丢弃。

  • 在与服务帐户相同的命名空间中发生的 Service Account 写入事件将被丢弃。

  • 所有其他事件都将被转发，但须遵守任何已配置的速率限制。

要禁用这些默认设置，请将规则列表的结尾处添加一个仅包含level字段的规则，或添加一个空规则。

忽略响应代码

要忽略的整数状态代码列表。您可以使用OmitResponseCodes字段（一个 HTTP 状态代码列表，不会为此创建事件）根据响应中的 HTTP 状态代码丢弃事件。默认值为[404, 409, 422, 429]。如果值为空列表[]，则不会忽略任何状态代码。

ClusterLogForwarder CR 审计策略除了 Red Hat OpenShift Service on AWS 审计策略之外还会生效。ClusterLogForwarder CR 审计过滤器会更改日志收集器转发的内容，并提供按动词、用户、组、命名空间或资源进行过滤的功能。您可以创建多个过滤器，将同一审计流的不同摘要发送到不同位置。例如，您可以将详细流发送到本地集群日志存储，并将不太详细的流发送到远程站点。

提供的示例旨在说明审计策略中可能的规则范围，而不是推荐的配置。
审计策略示例
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-pipeline
      inputRefs: audit (1)
      filterRefs: my-policy (2)
      outputRefs: default
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata
1 收集的日志类型。此字段的值可以是审计日志的audit、应用程序日志的application、基础设施日志的infrastructure，或为您的应用程序定义的命名输入。
2 您的审计策略的名称。
其他资源
编辑

将日志转发到外部 Loki 日志系统

除了默认日志存储之外，您还可以将日志转发到外部 Loki 日志系统。

要配置到 Loki 的日志转发，您必须创建一个具有 Loki 输出和使用该输出的管道的ClusterLogForwarder自定义资源 (CR)。Loki 的输出可以使用 HTTP（不安全）或 HTTPS（安全 HTTP）连接。

先决条件

  • 您必须在 CR 中使用url字段指定的 URL 处运行 Loki 日志系统。

步骤

  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 对于安全连接，您可以指定一个https或http URL，您可以通过指定secret进行身份验证。
    8 对于https前缀，请指定端点对于 TLS 通信所需的密钥的名称。该密钥必须包含一个指向其代表的证书的ca-bundle.crt键。否则，对于http和https前缀，您可以指定一个包含用户名和密码的密钥。在旧版实现中，密钥必须存在于openshift-logging项目中。有关更多信息，请参阅以下“示例：设置包含用户名和密码的密钥”。
    9 可选：指定一个元数据键字段，以生成 Loki 中TenantID字段的值。例如，设置tenantKey: kubernetes.namespace_name使用 Kubernetes 命名空间的名称作为 Loki 中租户 ID 的值。要查看可以指定的其他日志记录字段，请参阅以下“其他资源”部分中的“日志记录字段”链接。
    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 限制了允许的标签的大小和数量。请参阅配置 Loki，limits_config。您仍然可以使用查询过滤器根据任何日志记录字段进行查询。
    11 可选：为管道指定名称。
    12 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    13 指定使用此管道转发日志时要使用的输出名称。

    由于 Loki 要求日志流按时间戳正确排序，因此即使您未指定 kubernetes_host 标签集，labelKeys 也始终包含它。此包含可确保每个流都源自单个主机，从而防止由于不同主机上的时钟差异导致时间戳无序。

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

    $ oc apply -f <filename>.yaml
其他资源
编辑

将日志转发到外部 Elasticsearch 实例

除了内部日志存储之外，您还可以将日志转发到外部 Elasticsearch 实例，或者完全替换内部日志存储。您负责配置外部日志聚合器以接收来自 AWS 上 Red Hat OpenShift Service 的日志数据。

要将日志转发到外部 Elasticsearch 实例，您必须创建一个具有指向该实例的输出和使用该输出的管道的 ClusterLogForwarder 自定义资源 (CR)。外部 Elasticsearch 输出可以使用 HTTP（不安全）或 HTTPS（安全 HTTP）连接。

要将日志同时转发到外部和内部 Elasticsearch 实例，请创建指向外部实例的输出和管道，以及使用 default 输出将日志转发到内部实例的管道。

如果您只想将日志转发到内部 Elasticsearch 实例，则无需创建 ClusterLogForwarder CR。
先决条件

  • 您必须拥有一个已配置为使用指定的协议或格式接收日志数据的日志服务器。

步骤

  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 通信所需的密钥名称。密钥必须包含一个指向其表示的证书的 ca-bundle.crt 密钥。否则，对于 http 和 https 前缀，您可以指定一个包含用户名和密码的密钥。在旧版实现中，密钥必须存在于 openshift-logging 项目中。有关更多信息，请参阅以下“示例：设置包含用户名和密码的密钥”。
    9 可选：为管道指定名称。
    10 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    11 指定使用此管道转发日志时要使用的输出名称。
    12 可选：指定 default 输出以将日志发送到内部 Elasticsearch 实例。
    13 可选：字符串。要添加到日志的一个或多个标签。

  2. 应用 ClusterLogForwarder CR

    $ oc apply -f <filename>.yaml
示例：设置包含用户名和密码的密钥

您可以使用包含用户名和密码的密钥来验证与外部 Elasticsearch 实例的安全连接。

例如，如果您无法使用双向 TLS (mTLS) 密钥（因为第三方操作 Elasticsearch 实例），则可以使用 HTTP 或 HTTPS 并设置包含用户名和密码的密钥。

  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

使用 Fluentd forward 协议转发日志

您可以使用 Fluentd **forward** 协议将日志副本发送到配置为接受该协议的外部日志聚合器，而不是默认的 Elasticsearch 日志存储，或者除了默认的 Elasticsearch 日志存储之外。您负责配置外部日志聚合器以接收来自 AWS 上 Red Hat OpenShift Service 的日志。

要使用 **forward** 协议配置日志转发，您必须创建一个具有一个或多个指向 Fluentd 服务器的输出和使用这些输出的管道的 ClusterLogForwarder 自定义资源 (CR)。Fluentd 输出可以使用 TCP（不安全）或 TLS（安全 TCP）连接。

先决条件

  • 您必须拥有一个已配置为使用指定的协议或格式接收日志数据的日志服务器。

步骤

  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 通信所需的密钥名称。密钥必须存在于 openshift-logging 项目中，并且必须包含一个指向其表示的证书的 ca-bundle.crt 密钥。
    7 可选：为管道指定名称。
    8 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    9 指定使用此管道转发日志时要使用的输出名称。
    10 可选：指定 default 输出以将日志转发到内部 Elasticsearch 实例。
    11 可选：字符串。要添加到日志的一个或多个标签。
    12 可选：配置多个输出以将日志转发到任何受支持类型的其他外部日志聚合器。

    • 描述管道的名称。

    • inputRefs 是要通过管道转发的日志类型：application、infrastructure 或 audit。

    • outputRefs是要使用的输出的名称。

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

  2. 创建 CR 对象

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

启用纳秒精度以使 Logstash 从 fluentd 摄取数据

要使 Logstash 从 fluentd 摄取日志数据，必须在 Logstash 配置文件中启用纳秒精度。

步骤

  • 在 Logstash 配置文件中，将 nanosecond_precision 设置为 true。

Logstash 配置文件示例
input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }

使用 syslog 协议转发日志

您可以使用 **syslog** RFC3164 或 RFC5424 协议将日志副本发送到配置为接受该协议的外部日志聚合器，而不是默认的 Elasticsearch 日志存储，或者除了默认的 Elasticsearch 日志存储之外。您负责配置外部日志聚合器（例如 syslog 服务器）以接收来自 AWS 上 Red Hat OpenShift Service 的日志。

要使用 **syslog** 协议配置日志转发，您必须创建一个具有一个或多个指向 syslog 服务器的输出和使用这些输出的管道的 ClusterLogForwarder 自定义资源 (CR)。syslog 输出可以使用 UDP、TCP 或 TLS 连接。

先决条件

  • 您必须拥有一个已配置为使用指定的协议或格式接收日志数据的日志服务器。

步骤

  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 通信所需的密钥名称。密钥必须包含一个指向其表示的证书的 ca-bundle.crt 密钥。在旧版实现中，密钥必须存在于 openshift-logging 项目中。
    9 可选：为管道指定名称。
    10 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    11 指定使用此管道转发日志时要使用的输出名称。
    12 可选：指定 default 输出以将日志转发到内部 Elasticsearch 实例。
    13 可选：字符串。要添加到日志的一个或多个标签。引用诸如“true”之类的值，以便它们被识别为字符串值，而不是布尔值。
    14 可选：配置多个输出以将日志转发到任何受支持类型的其他外部日志聚合器。

    • 描述管道的名称。

    • inputRefs 是要通过管道转发的日志类型：application、infrastructure 或 audit。

    • outputRefs是要使用的输出的名称。

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

  2. 创建 CR 对象

    $ oc create -f <filename>.yaml
编辑

向消息输出添加日志源信息

您可以通过将 AddLogSource 字段添加到您的 ClusterLogForwarder 自定义资源 (CR) 来将 namespace_name、pod_name 和 container_name 元素添加到记录的 message 字段。

  spec:
    outputs:
    - name: syslogout
      syslog:
        addLogSource: true
        facility: user
        payloadKey: message
        rfc: RFC3164
        severity: debug
        tag: mytag
      type: syslog
      url: tls://syslog-receiver.openshift-logging.svc:24224
    pipelines:
    - inputRefs:
      - application
      name: test-app
      outputRefs:
      - syslogout

此配置与 RFC3164 和 RFC5424 均兼容。
不带 AddLogSource 的 syslog 消息输出示例
<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - -  {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}
带有 AddLogSource 的 syslog 消息输出示例
<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - -  namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}

Syslog 参数

您可以为 syslog 输出配置以下内容。有关更多信息，请参阅 syslog RFC3164 或 RFC5424 RFC。

  • facility：syslog facility。该值可以是十进制整数或不区分大小写的关键字。

    • 0 或 kern 用于内核消息

    • 1 或 user 用于用户级消息，这是默认值。

    • 2 或 mail 用于邮件系统

    • 3 或 daemon 用于系统守护进程

    • 4 或 auth 用于安全/身份验证消息

    • 5 或 syslog 用于 syslogd 内部生成的日志消息

    • 6 或 lpr 用于行式打印机子系统

    • 7 或 news 用于网络新闻子系统

    • 8 或 uucp 用于 UUCP 子系统

    • 9 或 cron 用于时钟守护进程

    • 10 或 authpriv 用于安全认证消息

    • 11 或 ftp 用于 FTP 守护进程

    • 12 或 ntp 用于 NTP 子系统

    • 13 或 security 用于 syslog 审计日志

    • 14 或 console 用于 syslog 警报日志

    • 15 或 solaris-cron 用于调度守护进程

    • 16–23 或 local0 – local7 用于本地使用的设施

  • 可选：payloadKey：用作 syslog 消息有效负载的记录字段。

    配置 payloadKey 参数可防止将其他参数转发到 syslog。

  • rfc：用于使用 syslog 发送日志的 RFC。默认为 RFC5424。

  • severity：要设置在传出 syslog 记录上的 syslog 严重性级别。值可以是小数整数或不区分大小写的关键字

    • 0 或 Emergency 用于指示系统不可用的消息

    • 1 或 Alert 用于指示必须立即采取措施的消息

    • 2 或 Critical 用于指示严重状况的消息

    • 3 或 Error 用于指示错误状况的消息

    • 4 或 Warning 用于指示警告状况的消息

    • 5 或 Notice 用于指示正常但重要的状况的消息

    • 6 或 Informational 用于指示信息性消息的消息

    • 7 或 Debug 用于指示调试级别消息的消息，默认为此级别

  • tag：Tag 指定用作 syslog 消息标签的记录字段。

  • trimPrefix：从标签中删除指定的前缀。

附加 RFC5424 syslog 参数

以下参数适用于 RFC5424

  • appName：APP-NAME 是一个自由文本字符串，用于标识发送日志的应用程序。必须为 RFC5424 指定。

  • msgID：MSGID 是一个自由文本字符串，用于标识消息类型。必须为 RFC5424 指定。

  • procID：PROCID 是一个自由文本字符串。值的更改表示 syslog 报告中的不连续性。必须为 RFC5424 指定。

编辑

将日志转发到 Kafka 代理

除了默认日志存储之外，还可以将日志转发到外部 Kafka 代理。

要配置将日志转发到外部 Kafka 实例，必须创建一个具有指向该实例的输出和使用该输出的管道的 ClusterLogForwarder 自定义资源 (CR)。可以在输出中包含特定的 Kafka 主题，也可以使用默认主题。Kafka 输出可以使用 TCP（不安全）或 TLS（安全 TCP）连接。

步骤

  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 通信所需的密钥的名称。密钥必须包含一个指向其代表的证书的 ca-bundle.crt 密钥。在旧版实现中，密钥必须存在于 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
编辑

将日志转发到 Amazon CloudWatch

可以将日志转发到 Amazon CloudWatch，这是一种由 Amazon Web Services (AWS) 托管的监控和日志存储服务。可以将日志转发到 CloudWatch，也可以代替默认日志存储。

要配置将日志转发到 CloudWatch，必须创建一个具有 CloudWatch 输出和使用该输出的管道的 ClusterLogForwarder 自定义资源 (CR)。

步骤

  1. 创建一个使用 aws_access_key_id 和 aws_secret_access_key 字段指定 base64 编码的 AWS 凭据的 Secret YAML 文件。例如

    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 命名空间必须为openshift-logging。在多日志转发器实现中，您可以使用任何命名空间。
    3 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
    4 指定输出的名称。
    5 指定 cloudwatch 类型。
    6 可选：指定如何分组日志

    • logType 为每种日志类型创建日志组。

    • namespaceName 为每个应用程序名称空间创建一个日志组。它还会为基础设施和审计日志创建单独的日志组。

    • namespaceUUID 为每个应用程序名称空间 UUID 创建一个新的日志组。它还会为基础设施和审计日志创建单独的日志组。
    7 可选：指定一个字符串来替换日志组名称中的默认 infrastructureName 前缀。
    8 指定 AWS 区域。
    9 指定包含 AWS 凭据的密钥的名称。
    10 可选：为管道指定名称。
    11 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    12 指定使用此管道转发日志时要使用的输出名称。

  4. 创建 CR 对象

    $ oc create -f <file-name>.yaml
示例：使用带有 Amazon CloudWatch 的 ClusterLogForwarder

在这里，您可以看到一个示例 ClusterLogForwarder 自定义资源 (CR) 及其输出到 Amazon CloudWatch 的日志数据。

假设您正在运行名为 mycluster 的 ROSA 集群。以下命令将返回集群的 infrastructureName，稍后您将使用它来组合 aws 命令

$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"

要为此示例生成日志数据，请在名为 app 的名称空间中运行 busybox pod。busybox pod 每三秒将一条消息写入标准输出

$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done'
$ oc logs -f busybox
My life is my message
My life is my message
My life is my message
...

您可以查找运行 busybox pod 的 app 名称空间的 UUID

$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"

在 ClusterLogForwarder 自定义资源 (CR) 中，您将 infrastructure、audit 和 application 日志类型配置为 all-logs 管道的输入。您还将此管道连接到 cw 输出，该输出将日志转发到 us-east-2 区域中的 CloudWatch 实例

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: cw
     type: cloudwatch
     cloudwatch:
       groupBy: logType
       region: us-east-2
     secret:
        name: cw-secret
  pipelines:
    - name: all-logs
      inputRefs:
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw

CloudWatch 中的每个区域包含三个级别的对象

  • 日志组

    • 日志流

      • 日志事件

在 ClusterLogForwarding CR 中使用 groupBy: logType 时，inputRefs 中的三种日志类型会在 Amazon Cloudwatch 中生成三个日志组

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.application"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

每个日志组都包含日志流

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName
"kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log"
...
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log"
...

每个日志流都包含日志事件。要查看来自 busybox Pod 的日志事件，请指定其来自 application 日志组的日志流

$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
{
    "events": [
        {
            "timestamp": 1629422704178,
            "message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
            "ingestionTime": 1629422744016
        },
...
示例：自定义日志组名称中的前缀

在日志分组名称中，您可以将默认的infrastructureName前缀（例如mycluster-7977k）替换为任意字符串，例如demo-group-prefix。要进行此更改，请更新ClusterLogForwarding CR中的groupPrefix字段。

cloudwatch:
    groupBy: logType
    groupPrefix: demo-group-prefix
    region: us-east-2

groupPrefix的值将替换默认的infrastructureName前缀。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"
示例：根据应用程序命名空间名称命名日志分组

对于集群中的每个应用程序命名空间，您可以在CloudWatch中创建一个日志分组，其名称基于应用程序命名空间的名称。

如果您删除应用程序命名空间对象并创建一个具有相同名称的新对象，CloudWatch将继续使用之前的相同日志分组。

如果您认为具有相同名称的连续应用程序命名空间对象彼此等效，请使用本示例中描述的方法。否则，如果您需要区分生成的日志分组，请参阅以下“根据应用程序命名空间UUID命名日志分组”部分。

要创建名称基于应用程序命名空间名称的应用程序日志分组，请在ClusterLogForwarder CR中将groupBy字段的值设置为namespaceName。

cloudwatch:
    groupBy: namespaceName
    region: us-east-2

将groupBy设置为namespaceName仅影响应用程序日志分组。它不影响audit和infrastructure日志分组。

在Amazon Cloudwatch中，命名空间名称出现在每个日志分组名称的末尾。因为只有一个应用程序命名空间“app”，所以以下输出显示一个新的mycluster-7977k.app日志分组，而不是mycluster-7977k.application。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.app"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

如果此示例中的集群包含多个应用程序命名空间，则输出将显示多个日志分组，每个命名空间一个。

groupBy字段仅影响应用程序日志分组。它不影响audit和infrastructure日志分组。

示例：根据应用程序命名空间UUID命名日志分组

对于集群中的每个应用程序命名空间，您可以在CloudWatch中创建一个日志分组，其名称基于应用程序命名空间的UUID。

如果您删除应用程序命名空间对象并创建一个新的对象，CloudWatch将创建一个新的日志分组。

如果您认为具有相同名称的连续应用程序命名空间对象彼此不同，请使用本示例中描述的方法。否则，请参阅前面的“示例：根据应用程序命名空间名称命名日志分组”部分。

要根据应用程序命名空间UUID命名日志分组，请在ClusterLogForwarder CR中将groupBy字段的值设置为namespaceUUID。

cloudwatch:
    groupBy: namespaceUUID
    region: us-east-2

在Amazon Cloudwatch中，命名空间UUID出现在每个日志分组名称的末尾。因为只有一个应用程序命名空间“app”，所以以下输出显示一个新的mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf日志分组，而不是mycluster-7977k.application。

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

groupBy字段仅影响应用程序日志分组。它不影响audit和infrastructure日志分组。

编辑

使用现有AWS角色创建AWS CloudWatch的密钥

如果您有现有的AWS角色，则可以使用oc create secret --from-literal命令使用STS创建AWS密钥。

步骤

  • 在CLI中，输入以下内容以生成AWS密钥：

    $ oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions
    密钥示例
    apiVersion: v1
kind: Secret
metadata:
  namespace: openshift-logging
  name: my-secret-name
stringData:
  role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions
编辑

从启用STS的集群将日志转发到Amazon CloudWatch

对于启用了AWS安全令牌服务(STS)的集群，您必须创建启用日志转发的AWS IAM角色和策略，以及带有CloudWatch输出的ClusterLogForwarder自定义资源(CR)。

先决条件

  • Red Hat OpenShift日志记录：5.5及更高版本

步骤

  1. 准备AWS账户

    1. 创建一个包含以下内容的IAM策略JSON文件：

      {
"Version": "2012-10-17",
"Statement": [
    {
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:DescribeLogGroups",
      "logs:DescribeLogStreams",
      "logs:PutLogEvents",
      "logs:PutRetentionPolicy"
    ],
    "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

    2. 创建一个包含以下内容的IAM信任JSON文件：

      {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>" (1)
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector" (2)
        }
      }
    }
  ]
}
      1 指定您的AWS账户ID和OpenShift OIDC提供程序端点。通过运行以下命令获取端点：
      $ rosa describe cluster \
  -c $(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}') \
  -o yaml | awk '/oidc_endpoint_url/ {print $2}' | cut -d '/' -f 3,4
      2 再次指定OpenShift OIDC端点。

    3. 创建IAM角色

      $ aws iam create-role
  --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
  --assume-role-policy-document file://<your_trust_file_name>.json \
  --query Role.Arn \
  --output text

      保存输出。您将在接下来的步骤中使用它。

    4. 创建IAM策略

      $ aws iam create-policy \
--policy-name "RosaCloudWatch" \
--policy-document file:///<your_policy_file_name>.json \
--query Policy.Arn \
--output text

      保存输出。您将在接下来的步骤中使用它。

    5. 将IAM策略附加到IAM角色

      $ aws iam attach-role-policy \
 --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
 --policy-arn <policy_ARN> (1)
      1 将policy_ARN替换为您在创建策略时保存的输出。

  2. 为Red Hat OpenShift日志记录操作符创建一个Secret YAML文件

    apiVersion: v1
kind: Secret
metadata:
  name: cloudwatch-credentials
  namespace: openshift-logging
stringData:
  credentials: |-
    [default]
    sts_regional_endpoints = regional
    role_arn: <role_ARN>  (1)
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
    1 将role_ARN替换为您在创建角色时保存的输出。

  3. 创建密钥

    $ oc apply -f cloudwatch-credentials.yaml

  4. 创建或编辑ClusterLogForwarder自定义资源

    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: <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 您的服务帐户的名称。只有在日志转发器未部署在openshift-logging命名空间中时，多日志转发器实现才需要服务帐户。
    4 指定输出的名称。
    5 指定 cloudwatch 类型。
    6 可选：指定如何分组日志

    • logType为每种日志类型创建日志分组

    • namespaceName为每个应用程序命名空间创建一个日志分组。基础架构和审核日志不受影响，仍然按logType分组。

    • namespaceUUID 为每个应用程序名称空间 UUID 创建一个新的日志组。它还会为基础设施和审计日志创建单独的日志组。
    7 可选：指定一个字符串来替换日志组名称中的默认 infrastructureName 前缀。
    8 指定 AWS 区域。
    9 指定您之前创建的密钥的名称。
    10 可选：为管道指定名称。
    11 使用管道指定要转发的日志类型：application、infrastructure 或 audit。
    12 指定使用此管道转发日志时要使用的输出名称。
其他资源