OpenShift comes with built-in Prometheus instances that you can use to monitor metrics for your workloads. Instead of using the built-in Prometheus that Gloo Mesh Enterprise provides, you might want to forward the metrics from the telemetry gateway and collector agents to the OpenShift Prometheus to have a single observability layer for all of your workloads in the cluster.

Single cluster

  1. Get the current values of the Helm release for your Gloo Mesh Enterprise installation. Note that your Helm release might have a different name.

      helm get values gloo-platform -n gloo-mesh -o yaml > gloo-single.yaml
    open gloo-single.yaml
      
  2. In your Helm values file, expose the otlp-metrics and metrics ports on the Gloo collector agent. The otlp-metrics port is used to expose the metrics that were collected by the telemetry collector agent from other workloads in the cluster. The metrics port exposes metrics for the Gloo telemetry collector agents themselves.

      
    telemetryCollector:
      enabled: true
      ports:
        otlp-metrics:
          containerPort: 9091
          enabled: true
          protocol: TCP
          servicePort: 9091
        metrics: 
          enabled: true
          containerPort: 8888
          servicePort: 8888
          protocol: TCP
      
  3. Upgrade your Helm release. Change the release name as needed.

      helm upgrade gloo-platform gloo-platform/gloo-platform \
      --namespace gloo-mesh \
      -f gloo-single.yaml \
      --version $GLOO_VERSION
      
  4. Verify that the Gloo telemetry collector deploys successfully.

      kubectl get pods -n gloo-mesh | grep telemetry
      
  5. Verify that the ports are exposed on the telemetry collector service.

      kubectl get services -n gloo-mesh | grep telemetry
      
  6. Create a configmap to enable workload monitoring in the cluster.

      kubectl apply -f - <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true
    EOF
      
  7. Create a service monitor resource to instruct the OpenShift Prometheus to scrape metrics from the Gloo telemetry collector agent. The service monitor scrapes metrics from the otlp-metrics and metrics ports that you exposed earlier.

      kubectl apply -f- <<EOF
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: gloo-telemetry-collector-sm
      namespace: gloo-mesh
    spec:
      endpoints:
      - interval: 30s
        port: otlp-metrics
        scheme: http
      - interval: 30s
        port: metrics
        scheme: http
      selector:
        matchLabels:
          app.kubernetes.io/name: telemetryCollector
    EOF
      
  8. Open the OpenShift web console and select the Administrator view.

  9. Navigate to Observe > Metrics to open the built-in Prometheus expression browser.

  10. Verify that you can see metrics for the telemetrycollector container. For example, you can enter otelcol_exporter_sent_metric_points in the expression browser and verify that these metrics were sent. For an overview of metrics that are exposed, see Default metrics in the pipeline.

Review the Next section for optional steps that might help you use metrics in OpenShift Prometheus.

Multicluster

Management cluster

  1. Get the current values of the Helm release for the management cluster. Note that your Helm release might have a different name.

      helm get values gloo-platform -n gloo-mesh -o yaml --kube-context $MGMT_CONTEXT > mgmt-server.yaml
    open mgmt-server.yaml
      
  2. In your Helm values file for the management cluster, expose the otlp-metrics and metrics ports on the Gloo telemetry gateway and the metrics port of the Gloo telemetry collector agent. The otlp-metrics port is used to expose the metrics that were collected by the telemetry collector agents across workload clusters and sent to the telemetry gateway. The metrics port exposes metrics for the Gloo telemetry gateway and collector agents themselves.

      
    telemetryGateway:
      enabled: true
      service:
        type: LoadBalancer
      ports:
        otlp-metrics:
          containerPort: 9091
          enabled: true
          protocol: TCP
          servicePort: 9091
        metrics: 
          enabled: true
          containerPort: 8888
          servicePort: 8888
          protocol: TCP
    telemetryCollector:
      enabled: true
      ports:
        otlp-metrics:
          containerPort: 9091
          enabled: true
          protocol: TCP
          servicePort: 9091       
        metrics: 
          enabled: true
          containerPort: 8888
          servicePort: 8888
          protocol: TCP
      
  3. Upgrade your Helm release in the management cluster. Change the release name as needed.

      helm upgrade gloo-platform gloo-platform/gloo-platform \
     --kube-context $MGMT_CONTEXT \
     --namespace gloo-mesh \
     -f mgmt-server.yaml \
     --version $GLOO_VERSION
      
  4. Verify that the Gloo telemetry gateway and collector agents deploy successfully.

      kubectl get pods --context $MGMT_CONTEXT -n gloo-mesh | grep telemetry
      
  5. Verify that the ports are exposed on the telemetry collector and gateway services.

      kubectl get services --context $MGMT_CONTEXT -n gloo-mesh | grep telemetry
      
  6. Create a configmap to enable workload monitoring for the management cluster.

      kubectl --context $MGMT_CONTEXT apply -f - <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true
    EOF
      
  7. Create a service monitor resource to instruct the OpenShift Prometheus to scrape metrics from the Gloo telemetry gateway. The service monitor scrapes metrics from the otlp-metrics and metrics ports that you exposed earlier.

      kubectl --context ${MGMT_CONTEXT} apply -f- <<EOF
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: gloo-telemetry-gateway-sm
      namespace: gloo-mesh
    spec:
      endpoints:
      - interval: 30s
        port: otlp-metrics
        scheme: http
      - interval: 30s
        port: metrics
        scheme: http
      selector:
        matchLabels:
          app.kubernetes.io/name: telemetryGateway
    EOF
      
  8. Create another service monitor to scrape metrics from the Gloo telemetry collector agent in the management cluster.

      kubectl --context ${MGMT_CONTEXT} apply -f- <<EOF
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: gloo-telemetry-collector-sm
      namespace: gloo-mesh
    spec:
      endpoints:
      - interval: 30s
        port: metrics
        scheme: http
      - interval: 30s
        port: otlp-metrics
        scheme: http
      selector:
        matchLabels:
          app.kubernetes.io/name: telemetryCollector
    EOF
      
  9. Open the OpenShift web console for the management cluster and select the Administrator view.

  10. Navigate to Observe > Metrics to open the built-in Prometheus expression browser.

  11. Verify that you can see metrics for the telemetrygateway and telemetrycollector containers. For example, you can enter otelcol_exporter_sent_metric_points in the expression browser and verify that these metrics were sent from both containers. For an overview of metrics that these two components expose, see Default metrics in the pipeline.

Workload cluster

  1. Get the current values of the Helm release for the workload cluster. Note that your Helm release might have a different name.

      helm get values gloo-platform -n gloo-mesh -o yaml --kube-context $REMOTE_CONTEXT > data-plane.yaml
    open data-plane.yaml
      
  2. In your Helm values file for the workload cluster, expose the metrics port on the Gloo telemetry collector agent. The metrics port exposes metrics for the Gloo telemetry collector agents, such as otelcol_exporter_enqueue_failed_metric_points, that you can use to determine whether the connection between the collector agents and the telemetry gateway in the management cluster is healthy.

      
    telemetryCollector:
      enabled: true
      ports:
        metrics: 
          enabled: true
          containerPort: 8888
          servicePort: 8888
          protocol: TCP
      
  3. Upgrade your Helm release in each workload cluster. Change the release name as needed. Be sure to update the cluster context for each workload cluster that you repeat this command for.

      helm upgrade gloo-platform gloo-platform/gloo-platform \
      --kube-context $REMOTE_CONTEXT \
      --namespace gloo-mesh \
      -f data-plane.yaml \
      --version $GLOO_VERSION
      
  4. Verify that the Gloo telemetry collector agents deploy successfully.

      kubectl get pods --context $REMOTE_CONTEXT -n gloo-mesh | grep telemetry
      
  5. Verify that the port is exposed on the telemetry collector service.

      kubectl get services --context $REMOTE_CONTEXT -n gloo-mesh | grep telemetry
      
  6. Create a service monitor to scrape metrics from the Gloo telemetry collector agent in the management cluster.

      kubectl --context ${REMOTE_CONTEXT} apply -f- <<EOF
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: gloo-telemetry-collector-sm
      namespace: gloo-mesh
    spec:
      endpoints:
      - interval: 30s
        port: metrics
        scheme: http
      selector:
        matchLabels:
          app.kubernetes.io/name: telemetryCollector
    EOF
      
  7. Create a configmap to enable workload monitoring for the workload cluster.

      kubectl --context $REMOTE_CONTEXT apply -f - <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true
    EOF
      
  8. Create a service monitor to scrape metrics from the istiod service mesh control plane.

      kubectl --context ${REMOTE_CONTEXT1} apply -f- <<EOF
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: istiod-http-monitoring
      namespace: istio-system
    spec:
      endpoints:
      - interval: 30s
        port: http-monitoring
        scheme: http
      selector:
        matchLabels:
          app: istiod
    EOF
      
  9. Open the OpenShift web console for the workload cluster and select the Administrator view.

  10. Navigate to Observe > Metrics to open the built-in Prometheus expression browser.

  11. Verify that you can see metrics for the telemetrycollector containers. For example, you can enter otelcol_exporter_sent_metric_points in the expression browser. For an overview of metrics that are exposed, see Default metrics in the pipeline.

  12. Optional: Repeat these steps for each workload cluster.

Review the Next section for optional steps that might help you use metrics in OpenShift Prometheus.

Next

Now that you set up metrics to flow from your Gloo Mesh Enterprise open telemetry pipeline to the OpenShift Prometheus, review the following options to do more with the metrics.

Gloo UI

You can update the Gloo UI to read metrics from the OpenShift Prometheus instance to populate the Gloo UI graph and other metrics. This way, you can remove the built-in Prometheus instance that Gloo Mesh Enterprise provides.

For more information, see Connect the Gloo UI to OpenShift Prometheus.

Alerts

Create alerts with your OpenShift monitoring tools. The following subsections show configuration files for Gloo, OTel, and Istio alerts.

For steps and more information about other metrics, review the following resources:

Translation alert

You might create an alert to monitor the translation time based on Gloo Mesh Enterprise metrics. The following example Prometheus rule creates an alert when translation time is higher than ten seconds (10).

For complex environments with thousands of services and many clusters, this translation time might be normal. You can adjust this time based on your environment and expected performance. For expected translation and other scalability thresholds, see the scalability docs.

Example Prometheus rule:

  kubectl --context ${MGMT_CONTEXT} apply -f- <<EOF
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: gloo-platform-translation-latency-is-high
  namespace: gloo-mesh
spec:
  groups:
  - name: GlooPlatformAlerts
    rules:
    - alert: GlooPlatformTranslationLatencyIsHigh
      for: 15m 
      expr: histogram_quantile(0.99, sum(rate(gloo_mesh_translation_time_sec_bucket[5m])) by(le)) > 10
      labels:
        severity: warning 
      annotations:
        runbook: https://docs.solo.io/gloo-mesh-enterprise/main/troubleshooting/gloo/server-relay/
        summary: The translation time exceeds 10 seconds.
EOF
  

OTel connectivity alert

You might create alerts to check the connectivity between the OTel gateways in the management cluster and the collectors in the workload clusters. For example, if the otelcol_exporter_queue_size metric increases consistently, this might indicate that the collectors can no longer send traffic to the gateway.

The following example sets up a warning if the OTel collector queue size exceeds 100. Adjust this value based on what is a normal queue size for your environment, so that you get alerted when the normal queue is exceeded. The default queue size is 1,000.

For more information about setting up monitoring for queues, see the OpenTelemetry docs.

Example Prometheus rule:

  kubectl --context ${MGMT_CONTEXT} apply -f- <<EOF
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: gloo-platform-otel-queue-is-high
  namespace: gloo-mesh
spec:
  groups:
  - name: GlooPlatformAlerts
    rules:
    - alert: GlooPlatformOTelQueueIsHigh
      for: 15m 
      expr: predict_linear(otelcol_exporter_queue_size[15m], 900) >= 100
      labels:
        severity: warning 
      annotations:
        runbook: https://docs.solo.io/gloo-mesh-enterprise/main/troubleshooting/gloo/telemetry/
        summary: The Gloo OTel queue is building up. If the queue size is increasing consistently, this might indicate network issues. Check the connectivity between the gateway and collectors for any issues.
EOF
  

Istio alert

You might create an alert to monitor the time that it takes for the Istio proxy to get a configuration change. The following example Prometheus rule creates an alert when proxy convergence time is higher than one minute (60 seconds).

For complex environments with thousands of services and many clusters, this translation time might be normal. You can adjust this time based on your environment and expected performance. For expected translation and other scalability thresholds, see the scalability docs.

Example Prometheus rule:

  kubectl --context ${MGMT_CONTEXT} apply -f- <<EOF
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: gloo-platform-istio-proxy-convergence-is-high
  namespace: gloo-mesh
spec:
  groups:
  - name: GlooPlatformAlerts
    rules:
    - alert: GlooPlatformIstioProxyConvergenceIsHigh
      for: 15m 
      expr: histogram_quantile(0.99, sum(rate(pilot_proxy_convergence_time_bucket[1m])) by (le)) > 60
      labels:
        severity: warning 
      annotations:
        runbook: https://docs.solo.io/gloo-mesh-enterprise/main/troubleshooting/service-mesh/istio/
        summary: The Istio proxy is taking more than 60 seconds to get configuration changes.
EOF