2.3. 升级到 Logging 6.0
日志记录 v6.0 是之前版本的一个显著升级,实现了集群日志记录的几个长目标:
- 引入不同的 operator 来管理日志记录组件(如收集器、存储、视觉化)。
- 根据 Elastic 产品(如 Elasticsearch、Kibana)删除对受管日志存储和视觉化的支持。
- 弃用 Fluentd 日志收集器实现。
-
删除对
ClusterLogging.logging.openshift.io
和ClusterLogForwarder.logging.openshift.io
资源的支持。
cluster-logging-operator 不提供自动升级过程。
根据日志集合、转发和存储的各种配置,cluster-logging-operator 不会提供自动升级。本文档可帮助管理员将现有 ClusterLogging.logging.openshift.io
和 ClusterLogForwarder.logging.openshift.io
规格转换为新的 API。包括针对常见用例迁移的 ClusterLogForwarder.observability.openshift.io
资源示例。
2.3.1. 使用 oc explain
命令
oc explain
命令是 OpenShift CLI oc
中的基本工具,它提供了自定义资源(CR)中字段的详细描述。此命令对于在 OpenShift 集群中配置或故障排除资源的管理员和开发人员而言是不可能的。
2.3.1.1. 资源描述
oc explain
提供了对与特定对象关联的所有字段的深入说明。这包括标准资源,如 pod 和服务,以及更复杂的实体,如有状态集和 Operator 定义的自定义资源。
要查看 ClusterLogForwarder
自定义资源的 outputs
字段的文档,您可以使用:
$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs
在 clusterlogforwarder
的位置,可以使用简短形式 obsclf
。
这将显示有关这些字段的详细信息,包括类型、默认值和任何关联的子字段。
2.3.1.2. 层次结构
命令以分级格式显示资源字段的结构,从而阐明不同配置选项之间的关系。
例如,以下是如何更深入地进行 storage
配置用于 LokiStack
自定义资源:
$ oc explain lokistacks.loki.grafana.com $ oc explain lokistacks.loki.grafana.com.spec $ oc explain lokistacks.loki.grafana.com.spec.storage $ oc explain lokistacks.loki.grafana.com.spec.storage.schemas
每个命令都显示了资源规格的深层次,使结构非常明确。
2.3.1.3. 类型信息
oc explain
也指示每个字段的类型(如字符串、整数或布尔值),允许您验证资源定义是否使用正确的数据类型。
例如:
$ oc explain lokistacks.loki.grafana.com.spec.size
这将显示 size
应使用整数值来定义。
2.3.1.4. 默认值
如果适用,命令会显示字段的默认值,以便在显式指定时了解哪些值将使用什么值。
再次使用 lokistacks.loki.grafana.com
作为示例:
$ oc explain lokistacks.spec.template.distributor.replicas
输出示例
GROUP: loki.grafana.com KIND: LokiStack VERSION: v1 FIELD: replicas <integer> DESCRIPTION: Replicas defines the number of replica pods of the component.
2.3.2. 日志存储
这个版本中唯一可用的受管日志存储解决方案是一个 Lokistack,由 loki-operator 管理。此解决方案以前作为受管 Elasticsearch 产品的首选替代方案提供,在部署过程中保持不变。
要继续使用 elasticsearch-operator 提供的现有红帽受管 Elasticsearch 或 Kibana 部署,请从名为 elasticsearch
的 Elasticsearch
资源中删除所有者引用,并在 openshift-logging
命名空间中删除名为 kibana
的 Kibana
资源,然后删除同一命名空间中名为 instance
的 ClusterLogging
资源。
临时将 ClusterLogging 设置为
Unmanaged
状态$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge
从 Elasticsearch 资源中删除 ClusterLogging
ownerReferences
以下命令确保 ClusterLogging 不再拥有 Elasticsearch 资源。对 ClusterLogging 资源的
logStore
字段的更新将不会影响 Elasticsearch 资源。$ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
从 Kibana 资源中删除 ClusterLogging
ownerReferences
以下命令确保 ClusterLogging 不再拥有 Kibana 资源。ClusterLogging 资源的
visualization
字段更新不再影响 Kibana 资源。$ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
-
将 ClusterLogging 设置为
Managed
状态
$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge
2.3.3. 日志可视化
用于日志视觉化的 OpenShift 控制台 UI 插件已从 cluster-logging-operator 移到 cluster-observability-operator 中。
2.3.4. 日志集合和转发
日志转发和转发配置现在在新的 API 下指定,这是 observability.openshift.io
API 组的一部分。以下小节重点介绍了与旧 API 资源的不同。
Vector 是唯一支持的收集器实现。
2.3.5. 管理、资源分配和工作负载调度
用于管理状态的配置(如 Managed、Unmanaged)、资源请求和限值、容限和节点选择现在是新的 ClusterLogForwarder API 的一部分。
以前的配置
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" spec: managementState: "Managed" collection: resources: limits: {} requests: {} nodeSelector: {} tolerations: {}
当前配置
apiVersion: "observability.openshift.io/v1" kind: ClusterLogForwarder spec: managementState: Managed collector: resources: limits: {} requests: {} nodeSelector: {} tolerations: {}
2.3.6. 输入规格
输入规格是 ClusterLogForwarder 规格的可选部分。管理员可以继续使用 application、infrastructure 和 audit 的预定义值来收集这些源。
2.3.6.1. 应用程序输入
命名空间和容器包含和排除项已整合到一个字段中。
使用 Namespace 和 Container Includes 和 Excludes 的 5.9 应用程序输入
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder spec: inputs: - name: application-logs type: application application: namespaces: - foo - bar includes: - namespace: my-important container: main excludes: - container: too-verbose
带有 Namespace 和 Container Includes 和 Excludes 的 6.0 应用程序输入
apiVersion: "observability.openshift.io/v1" kind: ClusterLogForwarder spec: inputs: - name: application-logs type: application application: includes: - namespace: foo - namespace: bar - namespace: my-important container: main excludes: - container: too-verbose
application, infrastructure, 和 audit 是保留词语,在定义输入时不能用作名称。
2.3.6.2. 输入接收者
对输入接收器的更改包括:
- 在接收器级别明确配置类型。
- 端口设置移到接收器级别。
5.9 Input Receivers
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder spec: inputs: - name: an-http receiver: http: port: 8443 format: kubeAPIAudit - name: a-syslog receiver: type: syslog syslog: port: 9442
6.0 Input Receivers
apiVersion: "observability.openshift.io/v1" kind: ClusterLogForwarder spec: inputs: - name: an-http type: receiver receiver: type: http port: 8443 http: format: kubeAPIAudit - name: a-syslog type: receiver receiver: type: syslog port: 9442
2.3.7. 输出规格
输出规格的高级更改包括:
- URL 设置移到每个输出类型规格中。
- 调整参数移到每个输出类型规格中。
- 将 TLS 配置与身份验证分离.
- 明确配置密钥和 secret/configmap,以用于 TLS 和身份验证。
2.3.8. secret 和 TLS 配置
现在,每个输出都会将 secret 和 TLS 配置划分为身份验证和 TLS 配置。它们必须在规格中明确定义,而不依赖于管理员使用可识别的密钥定义 secret。升级 TLS 和授权配置需要管理员了解之前识别的密钥才能继续使用现有的 secret。以下小节中的示例详细介绍了如何配置 ClusterLogForwarder secret 以转发到现有的红帽受管日志存储解决方案。
2.3.9. Red Hat Managed Elasticsearch
v5.9 转发到 Red Hat Managed Elasticsearch
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: logStore: type: elasticsearch
v6.0 转发到 Red Hat Managed Elasticsearch
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: default-elasticsearch type: elasticsearch elasticsearch: url: https://elasticsearch:9200 version: 6 index: <log_type>-write-{+yyyy.MM.dd} tls: ca: key: ca-bundle.crt secretName: collector certificate: key: tls.crt secretName: collector key: key: tls.key secretName: collector pipelines: - outputRefs: - default-elasticsearch - inputRefs: - application - infrastructure
在本例中,应用程序日志被写入 application-write
alias/index 中,而不是 app-write
。
2.3.10. Red Hat Managed LokiStack
v5.9 转发到 Red Hat Managed LokiStack
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: logStore: type: lokistack lokistack: name: lokistack-dev
v6.0 转发到 Red Hat Managed LokiStack
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: default-lokistack type: lokiStack lokiStack: target: name: lokistack-dev namespace: openshift-logging authentication: token: from: serviceAccount tls: ca: key: service-ca.crt configMapName: openshift-service-ca.crt pipelines: - outputRefs: - default-lokistack - inputRefs: - application - infrastructure
2.3.11. 过滤和管道配置
Pipeline 配置现在只定义到其输出目的地的输入源路由,任何所需的转换都会作为过滤器单独配置。本发行版本中管道的所有属性都已转换为过滤器。单个过滤器在 filters
规格中定义,并由管道引用。
5.9 过滤器
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder spec: pipelines: - name: application-logs parse: json labels: foo: bar detectMultilineErrors: true
6.0 过滤器配置
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder spec: filters: - name: detectexception type: detectMultilineException - name: parse-json type: parse - name: labels type: openShiftLabels openShiftLabels: foo: bar pipelines: - name: application-logs filterRefs: - detectexception - labels - parse-json
2.3.12. 验证和状态
在创建或更新资源时,会强制进行大多数验证,从而提供即时反馈。这与之前的版本不同,验证会在创建后发生,需要检查资源状态。有些验证仍然会在创建后进行,在创建或更新时无法验证。
ClusterLogForwarder.observability.openshift.io
的实例必须满足以下条件,然后才能部署日志收集器:Authorized、Valid、Ready。这些条件示例如下:
6.0 状态条件
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder status: conditions: - lastTransitionTime: "2024-09-13T03:28:44Z" message: 'permitted to collect log types: [application]' reason: ClusterRolesExist status: "True" type: observability.openshift.io/Authorized - lastTransitionTime: "2024-09-13T12:16:45Z" message: "" reason: ValidationSuccess status: "True" type: observability.openshift.io/Valid - lastTransitionTime: "2024-09-13T12:16:45Z" message: "" reason: ReconciliationComplete status: "True" type: Ready filterConditions: - lastTransitionTime: "2024-09-13T13:02:59Z" message: filter "detectexception" is valid reason: ValidationSuccess status: "True" type: observability.openshift.io/ValidFilter-detectexception - lastTransitionTime: "2024-09-13T13:02:59Z" message: filter "parse-json" is valid reason: ValidationSuccess status: "True" type: observability.openshift.io/ValidFilter-parse-json inputConditions: - lastTransitionTime: "2024-09-13T12:23:03Z" message: input "application1" is valid reason: ValidationSuccess status: "True" type: observability.openshift.io/ValidInput-application1 outputConditions: - lastTransitionTime: "2024-09-13T13:02:59Z" message: output "default-lokistack-application1" is valid reason: ValidationSuccess status: "True" type: observability.openshift.io/ValidOutput-default-lokistack-application1 pipelineConditions: - lastTransitionTime: "2024-09-13T03:28:44Z" message: pipeline "default-before" is valid reason: ValidationSuccess status: "True" type: observability.openshift.io/ValidPipeline-default-before
满足且适用的条件的 "status" 值为 "True"。状态不是 "True" 的条件会提供一个原因,并给出一个说明问题的消息。