Installing Logging

You can deploy the logging for Red Hat OpenShift by installing the Red Hat OpenShift Logging Operator. The Red Hat OpenShift Logging Operator creates and manages the components of the logging stack.

Logging is provided as an installable component, with a distinct release cycle from the core OKD. The Red Hat OpenShift Container Platform Life Cycle Policy outlines release compatibility.

For new installations, use Vector and LokiStack. Elasticsearch and Fluentd are deprecated and are planned to be removed in a future release.

Prerequisites

  • Ensure that you have downloaded the pull secret from the Red Hat OpenShift Cluster Manager as shown in Obtaining the installation program in the installation documentation for your platform.

    If you have the pull secret, add the redhat-operators catalog to the OperatorHub custom resource (CR) as shown in Configuring OKD to use Red Hat Operators.

Installing the Red Hat OpenShift Logging Operator by using the web console

You can install the Red Hat OpenShift Logging Operator by using the OKD web console.

Prerequisites

  • You have administrator permissions.

  • You have access to the OKD web console.

Procedure

  1. In the OKD web console, click Operators → OperatorHub.

  2. Type OpenShift Logging in the Filter by keyword box.

  3. Choose Red Hat OpenShift Logging from the list of available Operators, and click Install.

  4. Ensure that A specific namespace on the cluster is selected under Installation mode.

  5. Ensure that Operator recommended namespace is openshift-logging under Installed Namespace.

  6. Select Enable operator recommended cluster monitoring on this namespace.

    This option sets the openshift.io/cluster-monitoring: "true" label in the Namespace object. You must select this option to ensure that cluster monitoring scrapes the openshift-logging namespace.

  7. Select stable-5.y as the Update channel.

    The stable channel only provides updates to the most recent release of logging. To continue receiving updates for prior releases, you must change your subscription channel to stable-x.y, where x.y represents the major and minor version of logging you have installed. For example, stable-5.7.

  8. Select an Update approval.

    • The Automatic strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.

    • The Manual strategy requires a user with appropriate credentials to approve the Operator update.

  9. Select Enable or Disable for the Console plugin.

  10. Click Install.

Verification

  1. Verify that the Red Hat OpenShift Logging Operator is installed by switching to the Operators → Installed Operators page.

  2. In the Status column, verify that you see green checkmarks with InstallSucceeded and the text Up to date.

An Operator might display a Failed status before the installation finishes. If the Operator install completes with an InstallSucceeded message, refresh the page.

If the Operator does not show as installed, choose one of the following troubleshooting options:

  • Go to the Operators → Installed Operators page, and inspect the Status column for any errors or failures.

  • Go to the Workloads → Pods page, and check the logs in any pods in the openshift-logging project that are reporting issues.

Creating a ClusterLogging object by using the web console

After you have installed the logging Operators, you must create a ClusterLogging custom resource to configure log storage, visualization, and the log collector for your cluster.

Prerequisites

  • You have installed the Red Hat OpenShift Logging Operator.

  • You have access to the OKD web console Administrator perspective.

Procedure

  1. Navigate to the Custom Resource Definitions page.

  2. On the Custom Resource Definitions page, click ClusterLogging.

  3. On the Custom Resource Definition details page, select View Instances from the Actions menu.

  4. On the ClusterLoggings page, click Create ClusterLogging.

  5. In the collection section, select a Collector Implementation.

    Fluentd is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to Fluentd, you can use Vector instead.

  6. In the logStore section, select a type.

    The OpenShift Elasticsearch Operator is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to using the OpenShift Elasticsearch Operator to manage the default log storage, you can use the Loki Operator.

  7. Click Create.

Installing the Red Hat OpenShift Logging Operator by using the CLI

You can use the OpenShift CLI (oc) to install the Red Hat OpenShift Logging Operator.

Prerequisites

  • Ensure that you have downloaded the pull secret from the Red Hat OpenShift Cluster Manager as shown in Obtaining the installation program in the installation documentation for your platform.

    If you have the pull secret, add the redhat-operators catalog to the OperatorHub custom resource (CR) as shown in Configuring OKD to use Red Hat Operators.

  • You have administrator permissions.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. Create a Namespace object as a YAML file:

    Example Namespace object

    1. apiVersion: v1
    2. kind: Namespace
    3. metadata:
    4.   name: <name> (1)
    5.   annotations:
    6.     openshift.io/node-selector: ""
    7.   labels:
    8.     openshift.io/cluster-monitoring: "true"
    1You must specify openshift-logging as the name of the namespace for logging versions 5.7 and earlier versions. For logging 5.8 and later versions, you can use any name.

  2. Apply the Namespace object by running the following command:

    1. $ oc apply -f <filename>.yaml

  3. Create an OperatorGroup object as a YAML file:

    Example OperatorGroup object

    1. apiVersion: operators.coreos.com/v1
    2. kind: OperatorGroup
    3. metadata:
    4.   name: cluster-logging
    5.   namespace: openshift-logging (1)
    6. spec:
    7.   targetNamespaces:
    8.   - openshift-logging (1)
    1You must specify the openshift-logging namespace for logging versions 5.7 and older. For logging 5.8 and later versions, you can use any namespace.

  4. Apply the OperatorGroup object by running the following command:

    1. $ oc apply -f <filename>.yaml

  5. Create a Subscription object to subscribe the namespace to the Red Hat OpenShift Logging Operator:

    Example Subscription object

    1. apiVersion: operators.coreos.com/v1alpha1
    2. kind: Subscription
    3. metadata:
    4.   name: cluster-logging
    5.   namespace: openshift-logging (1)
    6. spec:
    7.   channel: stable (2)
    8.   name: cluster-logging
    9.   source: redhat-operators (3)
    10.   sourceNamespace: openshift-marketplace
    1You must specify the openshift-logging namespace for logging versions 5.7 and older. For logging 5.8 and later versions, you can use any namespace.
    2Specify stable or stable-x.y as the channel.
    3Specify redhat-operators. If your OKD cluster is installed on a restricted network, also known as a disconnected cluster, specify the name of the CatalogSource object you created when you configured the Operator Lifecycle Manager (OLM).

  6. Apply the subscription by running the following command:

    1. $ oc apply -f <filename>.yaml

    The Red Hat OpenShift Logging Operator is installed to the openshift-logging namespace.

Verification

  1. Run the following command:

    1. $ oc get csv -n <namespace>

  2. Observe the output and confirm that the Red Hat OpenShift Logging Operator exists in the namespace:

    Example output

    1. NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
    2. ...
    3. openshift-logging                                       clusterlogging.5.8.0-202007012112.p0         OpenShift Logging          5.8.0-202007012112.p0              Succeeded
    4. ...

Creating a ClusterLogging object by using the CLI

This default logging configuration supports a wide array of environments. Review the topics on tuning and configuring components for information about modifications you can make.

Prerequisites

  • You have installed the Red Hat OpenShift Logging Operator.

  • You have installed the OpenShift Elasticsearch Operator for your log store.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. Create a ClusterLogging object as a YAML file:

    Example ClusterLogging object

    1. apiVersion: logging.openshift.io/v1
    2. kind: ClusterLogging
    3. metadata:
    4.   name: instance (1)
    5.   namespace: openshift-logging
    6. spec:
    7.   managementState: Managed (2)
    8.   logStore:
    9.     type: elasticsearch (3)
    10.     retentionPolicy: (4)
    11.       application:
    12.         maxAge: 1d
    13.       infra:
    14.         maxAge: 7d
    15.       audit:
    16.         maxAge: 7d
    17.     elasticsearch:
    18.       nodeCount: 3 (5)
    19.       storage:
    20.         storageClassName: <storage_class_name> (6)
    21.         size: 200G
    22.       resources: (7)
    23.           limits:
    24.             memory: 16Gi
    25.           requests:
    26.             memory: 16Gi
    27.       proxy: (8)
    28.         resources:
    29.           limits:
    30.             memory: 256Mi
    31.           requests:
    32.             memory: 256Mi
    33.       redundancyPolicy: SingleRedundancy
    34.   visualization:
    35.     type: kibana (9)
    36.     kibana:
    37.       replicas: 1
    38.   collection:
    39.     type: fluentd (10)
    40.     fluentd: {}
    1The name must be instance.
    2The OpenShift Logging management state. In some cases, if you change the OpenShift Logging defaults, you must set this to Unmanaged. However, an unmanaged deployment does not receive updates until OpenShift Logging is placed back into a managed state.
    3Settings for configuring Elasticsearch. Using the CR, you can configure shard replication policy and persistent storage.
    4Specify the length of time that Elasticsearch should retain each log source. Enter an integer and a time designation: weeks(w), hours(h/H), minutes(m) and seconds(s). For example, 7d for seven days. Logs older than the maxAge are deleted. You must specify a retention policy for each log source or the Elasticsearch indices will not be created for that source.
    5Specify the number of Elasticsearch nodes. See the note that follows this list.
    6Enter the name of an existing storage class for Elasticsearch storage. For best performance, specify a storage class that allocates block storage. If you do not specify a storage class, OpenShift Logging uses ephemeral storage.
    7Specify the CPU and memory requests for Elasticsearch as needed. If you leave these values blank, the OpenShift Elasticsearch Operator sets default values that should be sufficient for most deployments. The default values are 16Gi for the memory request and 1 for the CPU request.
    8Specify the CPU and memory requests for the Elasticsearch proxy as needed. If you leave these values blank, the OpenShift Elasticsearch Operator sets default values that should be sufficient for most deployments. The default values are 256Mi for the memory request and 100m for the CPU request.
    9Settings for configuring Kibana. Using the CR, you can scale Kibana for redundancy and configure the CPU and memory for your Kibana nodes. For more information, see Configuring the log visualizer.
    10Settings for configuring Fluentd. Using the CR, you can configure Fluentd CPU and memory limits. For more information, see “Configuring Fluentd”.

    The maximum number of Elasticsearch control plane nodes is three. If you specify a nodeCount greater than 3, OKD creates three Elasticsearch nodes that are Master-eligible nodes, with the master, client, and data roles. The additional Elasticsearch nodes are created as data-only nodes, using client and data roles. Control plane nodes perform cluster-wide actions such as creating or deleting an index, shard allocation, and tracking nodes. Data nodes hold the shards and perform data-related operations such as CRUD, search, and aggregations. Data-related operations are I/O-, memory-, and CPU-intensive. It is important to monitor these resources and to add more Data nodes if the current nodes are overloaded.

    For example, if nodeCount=4, the following nodes are created:

    1. $ oc get deployment
    Example output
    1. NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    2. cluster-logging-operator       1/1     1            1           18h
    3. elasticsearch-cd-x6kdekli-1    1/1     1            1          6m54s
    4. elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
    5. elasticsearch-cdm-x6kdekli-2   1/1     1            1           6m49s
    6. elasticsearch-cdm-x6kdekli-3   1/1     1            1           6m44s

    The number of primary shards for the index templates is equal to the number of Elasticsearch data nodes.

Verification

You can verify the installation by listing the pods in the openshift-logging project.

  • List the pods by running the following command:

    1. $ oc get pods -n openshift-logging

    Observe the pods for components of the logging, similar to the following list:

    Example output

    1. NAME                                            READY   STATUS    RESTARTS   AGE
    2. cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
    3. elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
    4. elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
    5. elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
    6. collector-587vb                                   1/1     Running   0          2m26s
    7. collector-7mpb9                                   1/1     Running   0          2m30s
    8. collector-flm6j                                   1/1     Running   0          2m33s
    9. collector-gn4rn                                   1/1     Running   0          2m26s
    10. collector-nlgb6                                   1/1     Running   0          2m30s
    11. collector-snpkt                                   1/1     Running   0          2m28s
    12. kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

Postinstallation tasks

After you have installed the Red Hat OpenShift Logging Operator, you can configure your deployment by creating and modifying a ClusterLogging custom resource (CR).

If you are not using the Elasticsearch log store, you can remove the internal Elasticsearch logStore and Kibana visualization components from the ClusterLogging custom resource (CR). Removing these components is optional but saves resources. See Removing unused components if you do not use the Elasticsearch log store.

About the ClusterLogging custom resource

To make changes to your logging environment, create and modify the ClusterLogging custom resource (CR).

Sample ClusterLogging custom resource (CR)

  1. apiVersion: logging.openshift.io/v1
  2. kind: ClusterLogging
  3. metadata:
  4.   name: instance (1)
  5.   namespace: openshift-logging (2)
  6. spec:
  7.   managementState: Managed (3)
  8. # ...
1The CR name must be instance.
2The CR must be installed to the openshift-logging namespace.
3The Red Hat OpenShift Logging Operator management state. When the state is set to unmanaged, the Operator is in an unsupported state and does not receive updates.

Configuring log storage

You can configure which log storage type your logging uses by modifying the ClusterLogging custom resource (CR).

Prerequisites

  • You have administrator permissions.

  • You have installed the OpenShift CLI (oc).

  • You have installed the Red Hat OpenShift Logging Operator and an internal log store that is either the LokiStack or Elasticsearch.

  • You have created a ClusterLogging CR.

The OpenShift Elasticsearch Operator is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to using the OpenShift Elasticsearch Operator to manage the default log storage, you can use the Loki Operator.

Procedure

  1. Modify the ClusterLogging CR logStore spec:

    ClusterLogging CR example

    1. apiVersion: logging.openshift.io/v1
    2. kind: ClusterLogging
    3. metadata:
    4. # ...
    5. spec:
    6. # ...
    7.   logStore:
    8.     type: <log_store_type> (1)
    9.     elasticsearch: (2)
    10.       nodeCount: <integer>
    11.       resources: {}
    12.       storage: {}
    13.       redundancyPolicy: <redundancy_type> (3)
    14.     lokistack: (4)
    15.       name: {}
    16. # ...
    1Specify the log store type. This can be either lokistack or elasticsearch.
    2Optional configuration options for the Elasticsearch log store.
    3Specify the redundancy type. This value can be ZeroRedundancy, SingleRedundancy, MultipleRedundancy, or FullRedundancy.
    4Optional configuration options for LokiStack.

    Example ClusterLogging CR to specify LokiStack as the log store

    1. apiVersion: logging.openshift.io/v1
    2. kind: ClusterLogging
    3. metadata:
    4.   name: instance
    5.   namespace: openshift-logging
    6. spec:
    7.   managementState: Managed
    8.   logStore:
    9.     type: lokistack
    10.     lokistack:
    11.       name: logging-loki
    12. # ...

  2. Apply the ClusterLogging CR by running the following command:

    1. $ oc apply -f <filename>.yaml

Configuring the log collector

You can configure which log collector type your logging uses by modifying the ClusterLogging custom resource (CR).

Fluentd is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to Fluentd, you can use Vector instead.

Prerequisites

  • You have administrator permissions.

  • You have installed the OpenShift CLI (oc).

  • You have installed the Red Hat OpenShift Logging Operator.

  • You have created a ClusterLogging CR.

Procedure

  1. Modify the ClusterLogging CR collection spec:

    ClusterLogging CR example

    1. apiVersion: logging.openshift.io/v1
    2. kind: ClusterLogging
    3. metadata:
    4. # ...
    5. spec:
    6. # ...
    7.   collection:
    8.     type: <log_collector_type> (1)
    9.     resources: {}
    10.     tolerations: {}
    11. # ...
    1The log collector type you want to use for the logging. This can be vector or fluentd.

  2. Apply the ClusterLogging CR by running the following command:

    1. $ oc apply -f <filename>.yaml

Configuring the log visualizer

You can configure which log visualizer type your logging uses by modifying the ClusterLogging custom resource (CR).

Prerequisites

  • You have administrator permissions.

  • You have installed the OpenShift CLI (oc).

  • You have installed the Red Hat OpenShift Logging Operator.

  • You have created a ClusterLogging CR.

If you want to use the OKD web console for visualization, you must enable the logging Console Plugin. See the documentation about “Log visualization with the web console”.

Procedure

  1. Modify the ClusterLogging CR visualization spec:

    ClusterLogging CR example

    1. apiVersion: logging.openshift.io/v1
    2. kind: ClusterLogging
    3. metadata:
    4. # ...
    5. spec:
    6. # ...
    7.   visualization:
    8.     type: <visualizer_type> (1)
    9.     kibana: (2)
    10.       resources: {}
    11.       nodeSelector: {}
    12.       proxy: {}
    13.       replicas: {}
    14.       tolerations: {}
    15.     ocpConsole: (3)
    16.       logsLimit: {}
    17.       timeout: {}
    18. # ...
    1The type of visualizer you want to use for your logging. This can be either kibana or ocp-console. The Kibana console is only compatible with deployments that use Elasticsearch log storage, while the OKD console is only compatible with LokiStack deployments.
    2Optional configurations for the Kibana console.
    3Optional configurations for the OKD web console.

  2. Apply the ClusterLogging CR by running the following command:

    1. $ oc apply -f <filename>.yaml

Allowing traffic between projects when network isolation is enabled

Your cluster network plugin might enforce network isolation. If so, you must allow network traffic between the projects that contain the operators deployed by OpenShift Logging.

Network isolation blocks network traffic between pods or services that are in different projects. The logging installs the OpenShift Elasticsearch Operator in the openshift-operators-redhat project and the Red Hat OpenShift Logging Operator in the openshift-logging project. Therefore, you must allow traffic between these two projects.

OKD offers two supported choices for the network plugin, OpenShift SDN and OVN-Kubernetes. These two providers implement various network isolation policies.

OpenShift SDN has three modes:

network policy

This is the default mode. If no policy is defined, it allows all traffic. However, if a user defines a policy, they typically start by denying all traffic and then adding exceptions. This process might break applications that are running in different projects. Therefore, explicitly configure the policy to allow traffic to egress from one logging-related project to the other.

multitenant

This mode enforces network isolation. You must join the two logging-related projects to allow traffic between them.

subnet

This mode allows all traffic. It does not enforce network isolation. No action is needed.

OVN-Kubernetes always uses a network policy. Therefore, as with OpenShift SDN, you must configure the policy to allow traffic to egress from one logging-related project to the other.

Procedure

  • If you are using OpenShift SDN in multitenant mode, join the two projects. For example:

    1. $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging

  • Otherwise, for OpenShift SDN in network policy mode and OVN-Kubernetes, perform the following actions:

    1. Set a label on the openshift-operators-redhat namespace. For example:

      1. $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat

    2. Create a network policy object in the openshift-logging namespace that allows ingress from the openshift-operators-redhat, openshift-monitoring and openshift-ingress projects to the openshift-logging project. For example:

      1. apiVersion: networking.k8s.io/v1
      2. kind: NetworkPolicy
      3. metadata:
      4.   name: allow-from-openshift-monitoring-ingress-operators-redhat
      5. spec:
      6.   ingress:
      7.   - from:
      8.     - podSelector: {}
      9.   - from:
      10.     - namespaceSelector:
      11.         matchLabels:
      12.           project: "openshift-operators-redhat"
      13.   - from:
      14.     - namespaceSelector:
      15.         matchLabels:
      16.           name: "openshift-monitoring"
      17.   - from:
      18.     - namespaceSelector:
      19.         matchLabels:
      20.           network.openshift.io/policy-group: ingress
      21.   podSelector: {}
      22.   policyTypes:
      23.   - Ingress

Additional resources