Chapter 1. Upgrading to Logging 6.0
Logging v6.0 is a significant upgrade from previous releases, achieving several longstanding goals of Cluster Logging:
- Introduction of distinct operators to manage logging components (e.g., collectors, storage, visualization).
- Removal of support for managed log storage and visualization based on Elastic products (i.e., Elasticsearch, Kibana).
- Deprecation of the Fluentd log collector implementation.
-
Removal of support for
ClusterLogging.logging.openshift.io
andClusterLogForwarder.logging.openshift.io
resources.
The cluster-logging-operator does not provide an automated upgrade process.
Given the various configurations for log collection, forwarding, and storage, no automated upgrade is provided by the cluster-logging-operator. This documentation assists administrators in converting existing ClusterLogging.logging.openshift.io
and ClusterLogForwarder.logging.openshift.io
specifications to the new API. Examples of migrated ClusterLogForwarder.observability.openshift.io
resources for common use cases are included.
1.1. Using the oc explain command Copy linkLink copied to clipboard!
The oc explain
command is an essential tool in the OpenShift CLI oc
that provides detailed descriptions of the fields within Custom Resources (CRs). This command is invaluable for administrators and developers who are configuring or troubleshooting resources in an OpenShift cluster.
1.1.1. Resource Descriptions Copy linkLink copied to clipboard!
oc explain
offers in-depth explanations of all fields associated with a specific object. This includes standard resources like pods and services, as well as more complex entities like statefulsets and custom resources defined by Operators.
To view the documentation for the outputs
field of the ClusterLogForwarder
custom resource, you can use:
oc explain clusterlogforwarders.observability.openshift.io.spec.outputs
$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs
In place of clusterlogforwarder
the short form obsclf
can be used.
This will display detailed information about these fields, including their types, default values, and any associated sub-fields.
1.1.2. Hierarchical Structure Copy linkLink copied to clipboard!
The command displays the structure of resource fields in a hierarchical format, clarifying the relationships between different configuration options.
For instance, here’s how you can drill down into the storage
configuration for a LokiStack
custom resource:
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
$ 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
Each command reveals a deeper level of the resource specification, making the structure clear.
1.1.3. Type Information Copy linkLink copied to clipboard!
oc explain
also indicates the type of each field (such as string, integer, or boolean), allowing you to verify that resource definitions use the correct data types.
For example:
oc explain lokistacks.loki.grafana.com.spec.size
$ oc explain lokistacks.loki.grafana.com.spec.size
This will show that size
should be defined using an integer value.
1.1.4. Default Values Copy linkLink copied to clipboard!
When applicable, the command shows the default values for fields, providing insights into what values will be used if none are explicitly specified.
Again using lokistacks.loki.grafana.com
as an example:
oc explain lokistacks.spec.template.distributor.replicas
$ oc explain lokistacks.spec.template.distributor.replicas
Example output
1.2. Log Storage Copy linkLink copied to clipboard!
The only managed log storage solution available in this release is a Lokistack, managed by the loki-operator. This solution, previously available as the preferred alternative to the managed Elasticsearch offering, remains unchanged in its deployment process.
To continue using an existing Red Hat managed Elasticsearch or Kibana deployment provided by the elasticsearch-operator, remove the owner references from the Elasticsearch
resource named elasticsearch
, and the Kibana
resource named kibana
in the openshift-logging
namespace before removing the ClusterLogging
resource named instance
in the same namespace.
Temporarily set ClusterLogging to state
Unmanaged
oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge
$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Remove ClusterLogging
ownerReferences
from the Elasticsearch resourceThe following command ensures that ClusterLogging no longer owns the Elasticsearch resource. Updates to the ClusterLogging resource’s
logStore
field will no longer affect the Elasticsearch resource.oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
$ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Remove ClusterLogging
ownerReferences
from the Kibana resourceThe following command ensures that ClusterLogging no longer owns the Kibana resource. Updates to the ClusterLogging resource’s
visualization
field will no longer affect the Kibana resource.oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
$ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set ClusterLogging to state
Managed
oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge
$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3. Log Visualization Copy linkLink copied to clipboard!
The OpenShift console UI plugin for log visualization has been moved to the cluster-observability-operator from the cluster-logging-operator.
1.4. Log Collection and Forwarding Copy linkLink copied to clipboard!
Log collection and forwarding configurations are now specified under the new API, part of the observability.openshift.io
API group. The following sections highlight the differences from the old API resources.
Vector is the only supported collector implementation.
1.5. Management, Resource Allocation, and Workload Scheduling Copy linkLink copied to clipboard!
Configuration for management state (e.g., Managed, Unmanaged), resource requests and limits, tolerations, and node selection is now part of the new ClusterLogForwarder API.
Previous Configuration
Current Configuration
1.6. Input Specifications Copy linkLink copied to clipboard!
The input specification is an optional part of the ClusterLogForwarder specification. Administrators can continue to use the predefined values of application, infrastructure, and audit to collect these sources.
1.6.1. Application Inputs Copy linkLink copied to clipboard!
Namespace and container inclusions and exclusions have been consolidated into a single field.
5.9 Application Input with Namespace and Container Includes and Excludes
6.0 Application Input with Namespace and Container Includes and Excludes
application, infrastructure, and audit are reserved words and cannot be used as names when defining an input.
1.6.2. Input Receivers Copy linkLink copied to clipboard!
Changes to input receivers include:
- Explicit configuration of the type at the receiver level.
- Port settings moved to the receiver level.
5.9 Input Receivers
6.0 Input Receivers
1.7. Output Specifications Copy linkLink copied to clipboard!
High-level changes to output specifications include:
- URL settings moved to each output type specification.
- Tuning parameters moved to each output type specification.
- Separation of TLS configuration from authentication.
- Explicit configuration of keys and secret/configmap for TLS and authentication.
1.8. Secrets and TLS Configuration Copy linkLink copied to clipboard!
Secrets and TLS configurations are now separated into authentication and TLS configuration for each output. They must be explicitly defined in the specification rather than relying on administrators to define secrets with recognized keys. Upgrading TLS and authorization configurations requires administrators to understand previously recognized keys to continue using existing secrets. Examples in the following sections provide details on how to configure ClusterLogForwarder secrets to forward to existing Red Hat managed log storage solutions.
1.9. Red Hat Managed Elasticsearch Copy linkLink copied to clipboard!
v5.9 Forwarding to Red Hat Managed Elasticsearch
v6.0 Forwarding to Red Hat Managed Elasticsearch
1.10. Red Hat Managed LokiStack Copy linkLink copied to clipboard!
v5.9 Forwarding to Red Hat Managed LokiStack
v6.0 Forwarding to Red Hat Managed LokiStack
1.11. Filters and Pipeline Configuration Copy linkLink copied to clipboard!
Pipeline configurations now define only the routing of input sources to their output destinations, with any required transformations configured separately as filters. All attributes of pipelines from previous releases have been converted to filters in this release. Individual filters are defined in the filters
specification and referenced by a pipeline.
5.9 Filters
6.0 Filter Configuration
1.12. Validation and Status Copy linkLink copied to clipboard!
Most validations are enforced when a resource is created or updated, providing immediate feedback. This is a departure from previous releases, where validation occurred post-creation and required inspecting the resource status. Some validation still occurs post-creation for cases where it is not possible to validate at creation or update time.
Instances of the ClusterLogForwarder.observability.openshift.io
must satisfy the following conditions before the operator will deploy the log collector: Authorized, Valid, Ready. An example of these conditions is:
6.0 Status Conditions
Conditions that are satisfied and applicable have a "status" value of "True". Conditions with a status other than "True" provide a reason and a message explaining the issue.