红帽全球峰会第 3 章 Logging 6.1
3.1. 支持
logging 只支持本文档中介绍的配置选项。
不要使用任何其他配置选项，因为它们不被支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果您使用本文档中描述的配置以外的配置，您的更改会被覆盖，因为 Operator 旨在协调差异。
如果必须执行 OpenShift Container Platform 文档中未描述的配置，您需要将 Red Hat OpenShift Logging Operator 设置为 Unmanaged。不支持非受管日志记录实例，且不会接收更新，直到您将其状态返回为 Managed 为止。
日志记录作为一个可安装的组件提供，它有一个不同于 OpenShift Container Platform 的发布周期。Red Hat OpenShift Container Platform 生命周期政策 概述了发行版本兼容性。
Loki 是一个可横向扩展的、高度可用、多租户日志聚合系统，作为 Red Hat OpenShift 的日志记录的 GA 日志存储，可以使用 OpenShift Observability UI 视觉化。OpenShift Logging 提供的 Loki 配置是一个短期日志存储，旨在让用户使用收集的日志执行快速故障排除。为此，Loki 的 Red Hat OpenShift 配置的日志记录具有短期存储，并针对非常最新的查询进行了优化。
对于长期存储或长时间查询，用户应查找其集群外部的日志存储。Loki 大小只针对短期存储（最多 30 天）进行了测试并被支持。
Red Hat OpenShift 的 logging 是一个建议的收集器，以及应用程序、基础架构和审计日志的规范化程序。它旨在将日志转发到各种支持的系统。
Logging 不是：
- 一个大规模日志收集系统
- 兼容安全信息和事件监控 (SIEM)
- "自带" (BYO)日志收集器配置
- 历史或长日志的保留或存储
- 保证的日志接收器
- 安全存储 - 默认不存储审计日志
3.1.1. 支持的 API 自定义资源定义
下表描述了支持的日志记录 API。
| CustomResourceDefinition (CRD) | ApiVersion | 支持状态 |
|---|---|---|
| LokiStack | lokistack.loki.grafana.com/v1 | 从 5.5 支持 |
| RulerConfig | rulerconfig.loki.grafana/v1 | 5.7 支持 |
| AlertingRule | alertingrule.loki.grafana/v1 | 5.7 支持 |
| RecordingRule | recordingrule.loki.grafana/v1 | 5.7 支持 |
| LogFileMetricExporter | LogFileMetricExporter.logging.openshift.io/v1alpha1 | 从 5.8 支持 |
| ClusterLogForwarder | clusterlogforwarder.observability.openshift.io/v1 | 6.0 支持 |
3.1.2. 不支持的配置
您必须将 Red Hat OpenShift Logging Operator 设置为 Unmanaged 状态才能修改以下组件：
- 收集器配置文件
- collector daemonset
明确不支持的情形包括：
- 使用环境变量配置日志记录收集器。您不能使用环境变量来修改日志收集器。
- 配置日志收集器规范日志的方式。您无法修改默认日志规范化。
3.1.3. 非受管 Operator 的支持策略
Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管（unmanaged） 状态，它不会响应配置更改，也不会收到更新。
虽然它可以在非生产环境集群或调试过程中使用，但处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
可使用以下方法将 Operator 设置为非受管状态：
独立 Operator 配置
独立 Operator 的配置中具有
managementState参数。这可以通过不同的方法来访问，具体取决于 Operator。例如，Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源（CR）来达到此目的，而 Cluster Samples Operator 使用了集群范围配置资源。将
managementState参数更改为Unmanaged意味着 Operator 不会主动管理它的资源，也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态，因为它可能会损坏集群，需要手动恢复。警告将独立 Operator 更改为
非受管状态会导致不支持该特定组件和功能。报告的问题必须在受管（Managed）状态中可以重复出现才能继续获得支持。Cluster Version Operator (CVO) 覆盖
可将
spec.overrides参数添加到 CVO 配置中，以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的spec.overrides[].unmanaged参数设置为true会阻止集群升级并在设置 CVO 覆盖后提醒管理员：Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后，必须可以重现报告的问题方可获得支持。
3.1.4. 为红帽支持收集日志记录数据
在提交问题单时，向红帽支持提供有关集群的调试信息会很有帮助。
您可以使用 must-gather 工具来收集有关 项目级别资源、集群级资源和每个日志记录组件的诊断信息。为了获得快速支持，请提供 OpenShift Container Platform 和日志记录的诊断信息。
3.1.4.1. 关于 must-gather 工具
oc adm must-gather CLI 命令会收集最有助于解决问题的集群信息。
对于日志记录，must-gather 会收集以下信息：
- 项目级别资源，包括 Pod、配置映射、服务帐户、角色、角色绑定和事件
- 集群级资源，包括集群级别的节点、角色和角色绑定
-
openshift-logging和openshift-operators-redhat命名空间中的 OpenShift Logging 资源，包括日志收集器的健康状况、日志存储和日志可视化工具
在运行 oc adm must-gather 时，集群上会创建一个新 pod。在该 pod 上收集数据，并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。
3.1.4.2. 收集日志记录数据
您可以使用 oc adm must-gather CLI 命令来收集有关日志记录的信息。
流程
使用 must-gather 来收集日志信息：
-
进入要存储
must-gather信息的目录。 针对日志记录镜像运行
oc adm must-gather命令：$ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')must-gather工具会创建一个以当前目录中must-gather.local开头的新目录。例如：must-gather.local.4157245944708210408。从刚刚创建的
must-gather目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：$ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
- 在红帽客户门户中为您的问题单附上压缩文件。
