This is a cache of https://docs.okd.io/4.6/logging/config/cluster-logging-maintenance-support.html. It is a snapshot of the page at 2024-11-22T02:46:58.660+0000.
Maintenance and support - Configuring your cluster logging <strong>deployment</strong> | Logging | OKD 4.6
  1. Documentation
×

Maintenance and support

About unsupported configurations

The supported way of configuring cluster logging is by configuring it using the options described in this documentation. Do not use other configurations, as they are unsupported. Configuration paradigms might change across OKD 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 disappear because the OpenShift Elasticsearch Operator and Cluster Logging Operator reconcile any differences. The Operators reverse everything to the defined state by default and by design.

If you must perform configurations not described in the OKD documentation, you must set your Cluster Logging Operator or OpenShift Elasticsearch Operator to Unmanaged. An unmanaged cluster logging environment is not supported and does not receive updates until you return cluster logging to Managed.

Unsupported configurations

You must set the Cluster Logging Operator to the unmanaged state in order to modify the following components:

  • the Curator cron job

  • the Elasticsearch CR

  • the Kibana deployment

  • the fluent.conf file

  • the Fluentd daemon set

You must set the OpenShift Elasticsearch Operator to the unmanaged state in order to modify the following component:

  • the Elasticsearch deployment files.

Explicitly unsupported cases include:

  • Configuring default log rotation. You cannot modify the default log rotation configuration.

  • Configuring the collected log location. You cannot change the location of the log collector output file, which by default is /var/log/fluentd/fluentd.log.

  • Throttling log collection. You cannot throttle down the rate at which the logs are read in by the log collector.

  • Configuring log collection JSON parsing. You cannot format log messages in JSON.

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

  • Configuring Curator in scripted deployments. You cannot configure log curation in scripted deployments.

  • Using the Curator Action file. You cannot use the Curator config map to modify the Curator action file.

Support policy for unmanaged Operators

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.

While this can be helpful in non-production clusters or during debugging, Operators in an unmanaged state are unsupported and the cluster administrator assumes full control of the individual component configurations and upgrades.

An Operator can be set to an unmanaged state using the following methods:

  • Individual Operator configuration

    Individual Operators have a managementState parameter in their configuration. This can be accessed in different ways, depending on the Operator. For example, the Cluster 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 managementState parameter to Unmanaged means 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.

    Changing individual Operators to the Unmanaged state renders that particular component and functionality unsupported. Reported issues must be reproduced in Managed state for support to proceed.

  • Cluster Version Operator (CVO) overrides

    The spec.overrides parameter 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 the spec.overrides[].unmanaged parameter to true for a component blocks cluster upgrades and alerts the administrator after a CVO override has been set:

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.

    Setting a CVO override puts the entire cluster in an unsupported state. Reported issues must be reproduced after removing any overrides for support to proceed.