Chapter 4. Logging support policy
Review supported configurations, API compatibility, and support policies before planning your deployment.
Configuration paradigms might change across OpenShift Container Platform releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in this documentation, your changes will be overwritten, because Operators are designed to reconcile any differences.
If you must perform configurations not described in the OpenShift Container Platform documentation, you must set your Red Hat OpenShift Logging Operator to Unmanaged. An unmanaged logging instance is not supported and does not receive updates until you return its status to Managed.
Logging is provided as an installable component, with a distinct release cycle from the core OpenShift Container Platform. The Red Hat Red Hat OpenShift Logging Life Cycle Policy outlines release compatibility.
Loki is a horizontally scalable, highly available, multitenant log aggregation system offered as a GA log store for logging for Red Hat OpenShift that can be visualized with the OpenShift Observability UI. The Loki configuration provided by OpenShift Logging is a short-term log store designed to help users perform fast troubleshooting with the collected logs. For that purpose, the logging for Red Hat OpenShift configuration of Loki has short-term storage, and is optimized for very recent queries. For long-term storage or queries over a long time period, users should look to log stores external to their cluster.
Elasticsearch indexes incoming log records completely during ingestion. Loki indexes only a few fixed labels during ingestion and defers more complex parsing until after the logs have been stored. This means Loki can collect logs more quickly.
4.1. Supported API custom resource definitions Copy linkLink copied to clipboard!
The following table describes the supported Logging APIs.
| CustomResourceDefinition (CRD) | ApiVersion | Support state |
|---|---|---|
| LokiStack | lokistack.loki.grafana.com/v1 | Supported from 5.5 |
| RulerConfig | rulerconfig.loki.grafana/v1 | Supported from 5.7 |
| AlertingRule | alertingrule.loki.grafana/v1 | Supported from 5.7 |
| RecordingRule | recordingrule.loki.grafana/v1 | Supported from 5.7 |
| LogFileMetricExporter | LogFileMetricExporter.logging.openshift.io/v1alpha1 | Supported from 5.8 |
| ClusterLogForwarder | clusterlogforwarder.observability.openshift.io/v1 | Supported from 6.0 |
4.2. Unsupported configurations Copy linkLink copied to clipboard!
You must set the Red Hat OpenShift Logging Operator to the Unmanaged state to modify the following components:
- The collector configuration file
- The collector daemonset
Explicitly unsupported cases include:
- Configuring the logging collector using environment variables. You cannot use environment variables to modify the log collector.
- Configuring how the log collector normalizes logs. You cannot modify default log normalization.
4.3. Support policy for unmanaged Operators Copy linkLink copied to clipboard!
The management state of an Operator determines whether an Operator is actively managing the resources for its related component in the cluster as designed. If an Operator is set to an unmanaged state, it does not respond to changes in configuration nor does it receive updates.
Although useful for non-production or debugging, Operators in an unmanaged state are unsupported, and the cluster administrator assumes full responsibility for configuration and upgrades.
An Operator can be set to an unmanaged state by using the following methods:
Individual Operator configuration
Individual Operators have a
managementStateparameter in their configuration. This can be accessed in different ways, depending on the Operator. For example, the Red Hat OpenShift Logging Operator accomplishes this by modifying a custom resource (CR) that it manages, while the Cluster Samples Operator uses a cluster-wide configuration resource.Changing the
managementStateparameter toUnmanagedmeans that the Operator is not actively managing its resources and will take no action related to the related component. Some Operators might not support this management state as it might damage the cluster and require manual recovery.WarningChanging individual Operators to the
Unmanagedstate renders that particular component and functionality unsupported. Reported issues must be reproduced inManagedstate for support to proceed.Cluster Version Operator (CVO) overrides
The
spec.overridesparameter can be added to the CVO’s configuration to allow administrators to provide a list of overrides to the CVO’s behavior for a component. Setting thespec.overrides[].unmanagedparameter totruefor a component blocks cluster upgrades and alerts the administrator after a CVO override has been set:Example output
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.WarningSetting a CVO override puts the entire cluster in an unsupported state. Reported issues must be reproduced after removing any overrides for support to proceed.