As an administrator, you can deploy cluster logging to aggregate logs for a range of OpenShift Dedicated services.

Cluster logging runs on worker nodes. As an administrator, you can monitor resource consumption in the console and via Prometheus and Grafana. Due to the high work load required for logging, more worker nodes may be required for your environment.

Logs in OpenShift Dedicated are retained for seven days before rotation. Logging storage is capped at 600GiB. This is independent of a cluster’s allocated base storage.

Cluster logging

OpenShift Dedicated administrators can deploy Cluster Logging and Elasticsearch operators via OperatorHub and configure logging in the openshift-logging namespace. Configuring logging will deploy Elasticsearch, Fluentd, and Kibana in the openshift-logging namespace. The operators are responsible for deploying, upgrading, and maintaining cluster logging.

You can configure cluster logging by modifying the Cluster Logging Custom Resource (CR), named instance. The CR defines a complete cluster logging deployment that includes all the components of the logging stack to collect, store and visualize logs. The Cluster Logging Operator watches the ClusterLogging Custom Resource and adjusts the logging deployment accordingly.

Administrators and application developers can view the logs of the projects for which they have view access.

Cluster logging components

The cluster logging components are based upon Elasticsearch, Fluentd, and Kibana (EFK). The collector, Fluentd, is deployed to each node in the OpenShift Dedicated cluster. It collects all node and container logs and writes them to Elasticsearch (ES). Kibana is the centralized, web UI where users and administrators can create rich visualizations and dashboards with the aggregated data.

There are currently 5 different types of cluster logging components:

  • logStore - This is where the logs will be stored. The current implementation is Elasticsearch.

  • collection - This is the component that collects logs from the node, formats them, and stores them in the logStore. The current implementation is Fluentd.

  • visualization - This is the UI component used to view logs, graphs, charts, and so forth. The current implementation is Kibana.

  • curation - This is the component that trims logs by age. The current implementation is Curator.

In this document, we may refer to logStore or Elasticsearch, visualization or Kibana, curation or Curator, collection or Fluentd, interchangeably, except where noted.

About the log store

OpenShift Dedicated uses Elasticsearch (ES) to organize the log data from Fluentd into datastores, or indices.

Elasticsearch subdivides each index into multiple pieces called shards, which it spreads across a set of Elasticsearch nodes in an Elasticsearch cluster. You can configure Elasticsearch to make copies of the shards, called replicas. Elasticsearch also spreads these replicas across the Elasticsearch nodes. The ClusterLogging Custom Resource allows you to specify the replication policy in the Custom Resource Definition (CRD) to provide data redundancy and resilience to failure.

The cluster logging Elasticsearch instance is optimized and tested for short term storage of approximately seven days. If you want to retain your logs over a longer term, it is recommended that you move the data to a third-party storage system.

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

The Cluster Logging Operator and companion Elasticsearch Operator ensure that each Elasticsearch node is deployed using a unique Deployment that includes its own storage volume. You can use a Cluster Logging Custom Resource (CR) to increase the number of Elasticsearch nodes. Refer to Elastic’s documentation for considerations involved in choosing storage and network location as directed below.

A highly-available Elasticsearch environment requires at least three Elasticsearch nodes, each on a different host.

Role-based access control (RBAC) applied on the Elasticsearch indices enables the controlled access of the logs to the developers. Access to the indexes with the project.{project_name}.{project_uuid}.* format is restricted based on the permissions of the user in the specific project.

For more information, see Elasticsearch (ES).

About the logging collector

OpenShift Dedicated uses Fluentd to collect data about your cluster.

The logging collector is deployed as a DaemonSet in OpenShift Dedicated that deploys pods to each OpenShift Dedicated node. journald is the system log source supplying log messages from the operating system, the container runtime, and OpenShift Dedicated.

The container runtimes provide minimal information to identify the source of log messages: project, pod name, and container id. This is not sufficient to uniquely identify the source of the logs. If a pod with a given name and project is deleted before the log collector begins processing its logs, information from the API server, such as labels and annotations, might not be available. There might not be a way to distinguish the log messages from a similarly named pod and project or trace the logs to their source. This limitation means log collection and normalization is considered best effort.

The available container runtimes provide minimal information to identify the source of log messages and do not guarantee unique individual log messages or that these messages can be traced to their source.

For more information, see Fluentd.

About logging visualization

OpenShift Dedicated uses Kibana to display the log data collected by Fluentd and indexed by Elasticsearch.

Kibana is a browser-based console interface to query, discover, and visualize your Elasticsearch data through histograms, line graphs, pie charts, heat maps, built-in geospatial support, and other visualizations.

For more information, see Kibana.

About logging curation

The Elasticsearch Curator tool performs scheduled maintenance operations on a global and/or on a per-project basis. Curator performs actions based on its configuration. Only one Curator Pod is recommended per Elasticsearch cluster.

  type: "curator"
    schedule: "30 3 * * *" (1)
1 Specify the Curator schedule in the cron format.

For more information, see Curator.

About event routing

The Event Router is a Pod that watches OpenShift Dedicated events so they can be collected by cluster logging. The Event Router collects events from all projects and writes them to STDOUT. Fluentd collects those events and forwards them into the OpenShift Dedicated Elasticsearch instance. Elasticsearch indexes the events to the infra index.

You must manually deploy the Event Router.

About the Cluster Logging Custom Resource

To make changes to your cluster logging deployment, create and modify the Cluster Logging Custom Resource (CR). Instructions for creating or modifying a CR are provided in this documentation as appropriate.

The following is an example of a typical Custom Resource for cluster logging.

Sample Cluster Logging CR
apiVersion: ""
kind: "ClusterLogging"
  name: "instance"
  namespace: "openshift-logging"
  managementState: "Managed"
    type: "elasticsearch"
      nodeCount: 3
        storageClassName: "gp2"
        size: "200Gi"
      redundancyPolicy: "SingleRedundancy"
      nodeSelector: ""
          memory: 8G
    type: "kibana"
      replicas: 1
      nodeSelector: ""
    type: "curator"
      schedule: "30 3 * * *"
      nodeSelector: ""
      type: "fluentd"
      fluentd: {}
      nodeSelector: ""