Language:
Format:

Language:
Format:

2.4. 配置日志记录部署

您可以使用每个 Operator 实施的自定义资源 (CR) YAML 文件配置日志记录子系统部署。

Red Hat Openshift Logging Operator:

ClusterLogging (CL)- 部署收集器和转发器，它们目前都由每个节点上运行的 daemonset 实施。
ClusterLogForwarder (CLF)- 生成收集器配置，以为每个用户配置转发日志。

Loki Operator ：

LokiStack - 将 Loki 集群控制为日志存储，以及带有 OpenShift Container Platform 身份验证集成的 Web 代理，以强制实施多租户。

OpenShift Elasticsearch Operator ：

注意

这些 CR 由 ClusterLogging Operator 生成和管理，在没有使用 Operator 进行覆盖的情况下无法手动更改它们。

Elasticsearch - 配置和部署 Elasticsearch 实例作为默认日志存储。
Kibana - 配置和部署 Kibana 实例以搜索、查询和查看日志。

为 Red Hat OpenShift 配置日志记录子系统的支持方法是使用本文档中介绍的选项进行配置。请勿使用其他配置，因为不受支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果使用本文档中描述的配置以外的配置，您的更改可能会丢失，因为 Operator 会协调差异。按照设计，Operator 会默认将一切还原到定义的状态。

注意

如果必须执行 OpenShift Container Platform 文档中未描述的配置，您需要将 Red Hat OpenShift Logging Operator 设置为 Unmanaged。一个不受管理的 OpenShift Logging 环境不被支持，且不会接收更新，直到 OpenShift Logging 返回到 Managed。

2.4.1. 使用 Loki 启用基于流的保留

使用日志记录版本 5.6 及更高版本，您可以根据日志流配置保留策略。这些规则可全局设置，每个租户或两个都设置。如果同时配置这两个，则租户规则会在全局规则之前应用。

要启用基于流的保留，请创建或编辑 LokiStack 自定义资源 (CR)：

oc create -f <file-name>.yaml

您可以参考以下示例来配置 LokiStack CR。

全局的基于流的保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: standard
  tenants:
    mode: openshift-logging

1: 为所有日志流设置保留策略。注：此字段不会影响存储在对象存储中的保留周期。
2: 当此块被添加到 CR 时，集群中会启用保留。
3: 包含用于定义日志流的 LogQL 查询。

针对一个租户的基于流的保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: standard
  tenants:
    mode: openshift-logging

1

根据租户设置保留策略。有效的租户类型是 application、audit 和 infrastructure。

2

包含用于定义日志流的 LogQL 查询。

然后应用您的配置：

oc apply -f <file-name>.yaml

注意

这不适用于为存储的日志管理保留。使用对象存储配置存储在支持的最大 30 天的全局保留周期。

2.4.2. 启用多行异常检测

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

警告

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

日志解析器通常会错误地将同一个例外中的不同的行识别为不同的例外。这会导致额外的日志条目，以及要跟踪的信息的不完整或不正确。

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) 包含 detectMultilineErrors 字段，值为 true。

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.4.2.1. 详情

当日志消息作为一系列针对一个例外的信息出现时，会将它们合并到一个统一的日志记录中。第一个日志消息的内容被替换为序列中所有消息字段的连接内容。

表 2.2. 每个收集器支持的语言：

语言	Fluentd	Vector
Java	✓	✓
JS	✓	✓
Ruby	✓	✓
Python	✓	✓
Golang	✓	✓
PHP	✓
Dart	✓	✓

2.4.2.2. 故障排除

启用后，收集器配置将包括一个新的部分，类型是：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 config 部分的示例

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

2.4.3. 使用 Loki 启用基于日志的警报

Loki 警报规则使用 LogQL，并遵循 Prometheus 格式。您可以通过一个创建 AlertingRule 自定义资源 (CR) 来设置基于日志的警报。您可以为 application, audit, 或 infrastructure 租户创建AlertingRule CR。

租户类型	有效命名空间
application
audit	`openshift-logging`
infrastructure	`openshift-/`, `kube-/\`, `default`

在默认情况下，应用程序、审计和基础架构警报发送到 openshift-monitoring 命名空间中的 Cluster Monitoring Operator (CMO) Alertmanager，除非您已禁用了本地 Alertmanager 实例。

除非启用了单独的 Alertmanager 实例，应用程序警报默认不会发送到 openshift-user-workload-monitoring 命名空间中的 CMO Alertmanager。

AlertingRule CR 包含一组规格和 webhook 验证定义，用于声明单个 LokiStack 实例的警报规则组。另外，webhook 验证定义支持规则验证条件：

如果 AlertingRule CR 包含无效的 interval 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 for 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 LogQL expr，则它是一个无效的警报规则。
如果 AlertingRule CR 包含两个同名的组，则它是一个无效的警报规则。
如果以上都不适用，则 AlertingRule 被视为有效的警报规则。

先决条件

Red Hat OpenShift Operator 5.7 及更新版本的日志记录子系统
OpenShift Container Platform 4.13 及更新的版本

流程

创建 AlertingRule CR：
```
oc create -f <file-name>.yaml
```

使用适当的示例填充 AlertingRule CR：

基础架构 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/cluster-monitoring: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1: 在其中创建此 AlertingRule 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: infrastructure 租户的 AlertingRules 只在 openshift-*, kube-\*, 或 default 命名空间中被支持。
4: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
5: 必需字段。必须是 critical、warning 或 info。
6: 必需字段。
7: 必需字段。

应用程序 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/cluster-monitoring: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
            sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1: 在其中创建此 AlertingRule 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
4: 必需字段。必须是 critical、warning 或 info。
5: 必需字段。规则摘要。
6: 必需字段。规则的详细描述。

应用 CR。
```
oc apply -f <file-name>.yaml
```

Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

2.4. 配置日志记录部署

2.4.1. 使用 Loki 启用基于流的保留

2.4.2. 启用多行异常检测

2.4.2.1. 详情

2.4.2.2. 故障排除

2.4.3. 使用 Loki 启用基于日志的警报

Language and Page Formatting Options

2.4. 配置日志记录部署

2.4.1. 使用 Loki 启用基于流的保留

2.4.2. 启用多行异常检测

2.4.2.1. 详情

2.4.2.2. 故障排除

2.4.3. 使用 Loki 启用基于日志的警报