Observability

The Filelog and JournalD Receivers are a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope .

Configuring Cluster Observability Operator (COO) in ARO and Enabling remote writing of metrics to Azure Monitor Workspace

The Cluster Observability Operator (COO) is an optional OpenShift Container Platform Operator that enables administrators to create standalone monitoring stacks that are independently configurable for use by different services and users.

Deploying COO helps you address monitoring requirements that are hard to achieve using the default monitoring stack. COO is ideal for users who need high customizability, scalability, and long-term data retention, especially in complex, multi-tenant enterprise environments.

This guide will walk users through an example of how to use the COO to set up a highly available Prometheus instance that persists metrics, and enables remote writes of metrics to an Azure Monitor Prometheus

Deploying Grafana on Openshift 4

OpenShift users want access to a Grafana interface in order to build custom dashboards for their cluster and application workloads. The Grafana that shipped with OpenShift was read-only and has been deprecated in OpenShift 4.11 and removed in OpenShift 4.12 .

Since OpenShift uses Prometheus for both Cluster and User Workload metrics, its fairly straight forward to deploy a Grafana instance using the Grafana Operator and then view those cluster metrics and create custom Dashboards.

Configuring OpenShift Logging using LokiStack on ROSA and (soon) ARO

A guide to shipping logs and metrics on OpenShift using the new LokiStack setup. Recently, the default logging system with OpenShift swapped from ElasticSearch/FluentD/Kibana to a system based on LokiStack/Vector/OCP Console. LokiStack requires an object store in order to function, and this guide is designed to walk the user through the steps required to set this up.

Overview of the components of OpenShift Cluster Logging

Prerequisites

1. OpenShift CLI (oc)
2. Rights to install operators on the cluster
3. Access to create S3 buckets (AWS/ROSA), Blob Storage Container (Azure), Storage Bucket (GCP)

Setting up your environment for ROSA

1. Create environment variables to use later in this process by running the following commands:

1. Create the relevant AWS resources for LokiStack:

   OpenShift Logging

   A guide to shipping logs and metrics on OpenShift

   Prerequisites

   1. OpenShift CLI (oc)
   2. Rights to install operators on the cluster

   Setup OpenShift Logging

   This is for setup of centralized logging on OpenShift making use of Elasticsearch OSS edition. This largely follows the processes outlined in the OpenShift documentation here . Retention and storage considerations are reviewed in Red Hat’s primary source documentation.

   This setup is primarily concerned with simplicity and basic log searching. Consequently it is insufficient for long-lived retention or for advanced visualization of logs. For more advanced observability setups, you’ll want to look at Forwarding Logs to Third Party Systems

   Shipping logs to Azure Log Analytics

   This document follows the steps outlined by Microsoft in their documentation

   Follow docs.

   Step 4, needs additional command of:

   to capture resource ID of ARO cluster as well, needed for export in step 6

   bash enable-monitoring.sh --resource-id $azureAroV4ClusterResourceId --workspace-id $logAnalyticsWorkspaceResourceId works successfully

   can verify pods starting