Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Monitoring and logging

Red Hat Developer Hub 1.8

Tracking performance and capturing insights with monitoring and logging tools in Red Hat Developer Hub

Red Hat Customer Content Services

Abstract

As a Red Hat Developer Hub (RHDH) Operations or Project Manager, you can monitor performance and gather insights using Red Hat Developer Hub's monitoring and logging tools.

Chapter 1. Log Levels
Copy link

Logging is an essential part of monitoring and debugging software applications. It provides insight into how the application is functioning at runtime and can help you detect and diagnose issues. By adjusting the log level, you can control the amount and type of information displayed in the logs, ranging from highly detailed diagnostic output to the most critical errors. With this flexibility, you can customize logging output to match your current requirements, whether during development, testing, or production.

You can choose from the following log levels, listed in order of decreasing verbosity:

  • debug: Detailed information, typically useful only when troubleshooting.
  • info: General information about the operation of the application. This is the default level.
  • warn: Indicates potential issues or situations that might require attention.
  • error: Indicates errors that have occurred but might not prevent the application from continuing.
  • critical: Indicates critical errors that require immediate attention and are likely to prevent the application from functioning correctly.

You can control the verbosity of the logging by setting the log level. The log level determines the minimum severity level of events displayed in the console. For example, if the log level is set to 'info', events with a severity level of 'debug' are ignored.

To increase the log level, you can set the LOG_LEVEL environment variable to a higher severity level, such as 'warn' or 'error'. However, increasing the log level might not result in more output if the existing code primarily emits logs at lower severity levels, for example, 'debug' or 'info'. In such a case, adjust the logging statements within the code to use higher severity levels to see more output.

No additional steps are required beyond setting the LOG_LEVEL environment variable, but its effectiveness depends on the existing logging statements in the code.

In OpenShift Container Platform, metrics are exposed through an HTTP service endpoint under the /metrics canonical name. You can create a ServiceMonitor custom resource (CR) to scrape metrics from a service endpoint in a user-defined project.

You can enable and view metrics for an Operator-installed Red Hat Developer Hub instance from the OpenShift Container Platform web console. Metrics are exposed through an HTTP service endpoint under the /metrics canonical name.

By setting the spec.monitoring.enabled field to true in your Red Hat Developer Hub custom resource (CR), you instruct the Operator to automatically create and manage the necessary ServiceMonitor to scrape metrics from the service endpoint.

Prerequisites

  • Your OpenShift Container Platform cluster has monitoring for user-defined projects enabled.
  • You have installed Red Hat Developer Hub on OpenShift Container Platform using the Red Hat Developer Hub Operator.
  • You have installed the OpenShift CLI (oc).

Procedure

  1. Use the OpenShift CLI (oc) to edit your existing Red Hat Developer Hub CR. 

    oc edit Backstage <instance-name>
    Copy to Clipboard Toggle word wrap

  2. In the CR, locate the spec field and add the monitoring configuration block. 

    spec:
  monitoring:
    enabled: true
    Copy to Clipboard Toggle word wrap

  3. Save the RHDH CR. The RHDH Operator detects the configuration and automatically creates the corresponding ServiceMonitor custom resource (CR).

    Note

    The Operator automatically configures the ServiceMonitor with the correct labels (app.kubernetes.io/instance and app.kubernetes.io/name) that match your Backstage CR. The ServiceMonitor will be named metrics-<cr-name>. No additional label configuration is required.

Verification

  1. From the OpenShift Container Platform web console, select the Observe view.
  2. Click the Metrics tab to view metrics for Red Hat Developer Hub pods.
  3. From the OpenShift Container Platform web console, click Project > Services and verify the labels for backstage-developer-hub.

You can enable and view metrics for a Red Hat Developer Hub Helm deployment from the OpenShift Container Platform web console. Metrics monitoring is enabled through configuration during a chart upgrade. After the upgrade, the Helm release generates the necessary ServiceMonitor resource.

Prerequisites

  • Your OpenShift Container Platform cluster has monitoring for user-defined projects enabled.
  • You have installed Red Hat Developer Hub on OpenShift Container Platform using the Helm chart.

Procedure

  1. From the OpenShift Container Platform web console, select the Topology view.

  2. Click the overflow menu of the Red Hat Developer Hub Helm chart, and select Upgrade.

    helm upgrade
    View larger image
    helm upgrade

  3. On the Upgrade Helm Release page, select the YAML view option in Configure via, then configure the metrics section in the YAML, as shown in the following example: 

    upstream:
# ...
  metrics:
    serviceMonitor:
      enabled: true
      path: /metrics
      port: http-metrics
# ...
    Copy to Clipboard Toggle word wrap
    upgrade helm metrics
    View larger image
    upgrade helm metrics
  4. Click Upgrade.

Verification

  1. From the OpenShift Container Platform web console, select the Observe view.
  2. Click the Metrics tab to view metrics for Red Hat Developer Hub pods.

You can configure Red Hat Developer Hub to use Amazon CloudWatch for real-time monitoring and Amazon Prometheus for comprehensive logging. This is convenient when hosting Developer Hub on Amazon Web Services (AWS) infrastructure.

3.1. Monitoring with Amazon Prometheus
Copy link

You can configure Red Hat Developer Hub to use Amazon Prometheus for comprehensive logging. Amazon Prometheus extracts data from pods that have specific pod annotations.

3.1.1. Prerequisites
Copy link

To enable logging to Amazon Prometheus, you can configure the required pod annotations by using the Red Hat Developer Hub Operator.

Procedure

  1. As an administrator of the Red Hat Developer Hub Operator, edit the default configuration to add Prometheus annotations as follows: 

    # Update OPERATOR_NS accordingly
$ OPERATOR_NS=rhdh-operator
$ kubectl edit configmap backstage-default-config -n "${OPERATOR_NS}"
    Copy to Clipboard Toggle word wrap

  2. Find the deployment.yaml key in the config map and add the annotations to the spec.template.metadata.annotations field as follows: 

    deployment.yaml: |-
  apiVersion: apps/v1
  kind: Deployment
  # --- truncated ---
  spec:
    template:
      # --- truncated ---
      metadata:
        labels:
         rhdh.redhat.com/app:  # placeholder for 'backstage-<cr-name>'
        # --- truncated ---
        annotations:
          prometheus.io/scrape: 'true'
          prometheus.io/path: '/metrics'
          prometheus.io/port: '9464'
          prometheus.io/scheme: 'http'
  # --- truncated ---
    Copy to Clipboard Toggle word wrap
  3. Save your changes.

Verification

To verify if the scraping works:

  1. Use kubectl to port-forward the Prometheus console to your local machine as follows: 

    $ kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090
    Copy to Clipboard Toggle word wrap
  2. Open your web browser and navigate to http://localhost:9090 to access the Prometheus console.
  3. Monitor relevant metrics, such as process_cpu_user_seconds_total.

To enable logging to Amazon Prometheus, you can configure the required pod annotations by using the Red Hat Developer Hub Helm chart.

Procedure

  • To annotate the backstage pod for monitoring, update your values.yaml file as follows: 

    upstream:
  backstage:
    # --- TRUNCATED ---
    podAnnotations:
      prometheus.io/scrape: 'true'
      prometheus.io/path: '/metrics'
      prometheus.io/port: '9464'
      prometheus.io/scheme: 'http'
    Copy to Clipboard Toggle word wrap

Verification

To verify if the scraping works:

  1. Use kubectl to port-forward the Prometheus console to your local machine as follows: 

    kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090
    Copy to Clipboard Toggle word wrap
  2. Open your web browser and navigate to http://localhost:9090 to access the Prometheus console.
  3. Monitor relevant metrics, such as process_cpu_user_seconds_total.

3.2. Logging with Amazon CloudWatch
Copy link

Logging within the Red Hat Developer Hub relies on the Winston library.

You can configure the application log level by using the Red Hat Developer Hub Operator.

Procedure

  • Modify the logging level by including the environment variable LOG_LEVEL in your custom resource as follows: 

    spec:
  # Other fields omitted
  application:
    extraEnvs:
      envs:
        - name: LOG_LEVEL
          value: debug
    Copy to Clipboard Toggle word wrap

You can configure the application log level by using the Red Hat Developer Hub Helm chart.

Procedure

  • Modify the logging level by adding the environment variable LOG_LEVEL to your Helm chart values.yaml file: 

    upstream:
  backstage:
    # --- Truncated ---
    extraEnvVars:
      - name: LOG_LEVEL
        value: debug
    Copy to Clipboard Toggle word wrap

3.2.3. Retrieving logs from Amazon CloudWatch
Copy link

Prerequisites

  • CloudWatch Container Insights is used to capture logs and metrics for Amazon Elastic Kubernetes Service. For more information, see Logging for Amazon Elastic Kubernetes Service documentation.
  • To capture the logs and metrics, install the Amazon CloudWatch Observability EKS add-on in your cluster. Following the setup of Container Insights, you can access container logs using Logs Insights or Live Tail views.

  • CloudWatch names the log group where all container logs are consolidated in the following manner: 

    /aws/containerinsights/<cluster_name>/application
    Copy to Clipboard Toggle word wrap

Procedure

  • To retrieve logs from the Developer Hub instance, run a query such as: 

    fields @timestamp, @message, kubernetes.container_name
| filter kubernetes.container_name in ["install-dynamic-plugins", "backstage-backend"]
    Copy to Clipboard Toggle word wrap

Monitoring and logging are integral aspects of managing and maintaining Azure Kubernetes Services (AKS) in Red Hat Developer Hub. With features like Managed Prometheus Monitoring and Azure Monitor integration, administrators can efficiently monitor resource utilization, diagnose issues, and ensure the reliability of their containerized workloads.

4.1. Enabling Azure Monitor metrics
Copy link

To enable managed Prometheus monitoring, use the -enable-azure-monitor-metrics option within either the az aks create or az aks update command, depending on whether you’re creating a new cluster or updating an existing one, such as: 

az aks create/update --resource-group <your-ResourceGroup> --name <your-Cluster> --enable-azure-monitor-metrics
Copy to Clipboard Toggle word wrap

The previous command installs the metrics add-on, which gathers Prometheus metrics. Using the previous command, you can enable monitoring of Azure resources through both native Azure Monitor metrics. You can also view the results in the portal under Monitoring → Insights. For more information, see Monitor Azure resources with Azure Monitor.

Furthermore, metrics from both the Managed Prometheus service and Azure Monitor can be accessed through Azure Managed Grafana service. For more information, see Link a Grafana workspace section.

By default, Prometheus uses the minimum ingesting profile, which optimizes ingestion volume and sets default configurations for scrape frequency, targets, and metrics collected. The default settings can be customized through custom configuration. Azure offers various methods, including using different ConfigMaps, to provide scrape configuration and other metric add-on settings. For more information about default configuration, see Default Prometheus metrics configuration in Azure Monitor and Customize scraping of Prometheus metrics in Azure Monitor managed service for Prometheus documentation.

4.2. Configuring annotations for monitoring
Copy link

You can configure the annotations for monitoring Red Hat Developer Hub specific metrics in both Helm deployment and Operator-backed deployment.

Helm deployment

To annotate the backstage pod for monitoring, update your values.yaml file as follows: 

upstream:
  backstage:
    # --- TRUNCATED ---
    podAnnotations:
      prometheus.io/scrape: 'true'
      prometheus.io/path: '/metrics'
      prometheus.io/port: '9464'
      prometheus.io/scheme: 'http'
Copy to Clipboard Toggle word wrap
Operator-backed deployment

Procedure

  1. As an administrator of the operator, edit the default configuration to add Prometheus annotations as follows: 

    # Update OPERATOR_NS accordingly
OPERATOR_NS=rhdh-operator
kubectl edit configmap backstage-default-config -n "${OPERATOR_NS}"
    Copy to Clipboard Toggle word wrap

  2. Find the deployment.yaml key in the ConfigMap and add the annotations to the spec.template.metadata.annotations field as follows: 

    deployment.yaml: |-
  apiVersion: apps/v1
  kind: Deployment
  # --- truncated ---
  spec:
    template:
      # --- truncated ---
      metadata:
        labels:
         rhdh.redhat.com/app:  # placeholder for 'backstage-<cr-name>'
        # --- truncated ---
        annotations:
          prometheus.io/scrape: 'true'
          prometheus.io/path: '/metrics'
          prometheus.io/port: '9464'
          prometheus.io/scheme: 'http'
  # --- truncated ---
    Copy to Clipboard Toggle word wrap
  3. Save your changes.

Verification

To verify if the scraping works, navigate to the corresponding Azure Monitor Workspace and view the metrics under Monitoring → Metrics.

You can access live data logs generated by Kubernetes objects and collect log data in Container Insights within AKS.

Prerequisites

  • You have deployed Developer Hub on AKS.

For more information, see Installing Red Hat Developer Hub on Microsoft Azure Kubernetes Service.

Procedure

View live logs from your Developer Hub instance
  1. Navigate to the Azure Portal.
  2. Search for the resource group <your-ResourceGroup> and locate your AKS cluster <your-Cluster>.
  3. Select Kubernetes resources → Workloads from the menu.
  4. Select the <your-rhdh-cr>-developer-hub (in case of Helm Chart installation) or <your-rhdh-cr>-backstage (in case of Operator-backed installation) deployment.
  5. Click Live Logs in the left menu.

  6. Select the pod.

    Note

    There must be only single pod.

Live log data is collected and displayed.

View real-time log data from the Container Engine
  1. Navigate to the Azure Portal.
  2. Search for the resource group <your-ResourceGroup> and locate your AKS cluster <your-Cluster>.
  3. Select Monitoring → Insights from the menu.
  4. Go to the Containers tab.
  5. Find the backend-backstage container and click it to view real-time log data as it’s generated by the Container Engine.

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat