Managing metrics

You can collect metrics to monitor how cluster components and your own workloads are performing.

Understanding metrics

In OKD 4.11, cluster components are monitored by scraping metrics exposed through service endpoints. You can also configure metrics collection for user-defined projects.

You can define the metrics that you want to provide for your own workloads by using Prometheus client libraries at the application level.

In OKD, metrics are exposed through an HTTP service endpoint under the /metrics canonical name. You can list all available metrics for a service by running a curl query against http://<endpoint>/metrics. For instance, you can expose a route to the prometheus-example-app example service and then run the following to view all of its available metrics:

  1. $ curl http://<example_app_endpoint>/metrics

Example output

  1. # HELP http_requests_total Count of all HTTP requests
  2. # TYPE http_requests_total counter
  3. http_requests_total{code="200",method="get"} 4
  4. http_requests_total{code="404",method="get"} 2
  5. # HELP version Version information about this binary
  6. # TYPE version gauge
  7. version{version="v0.1.0"} 1

Additional resources

Setting up metrics collection for user-defined projects

You can create a ServiceMonitor resource to scrape metrics from a service endpoint in a user-defined project. This assumes that your application uses a Prometheus client library to expose metrics to the /metrics canonical name.

This section describes how to deploy a sample service in a user-defined project and then create a ServiceMonitor resource that defines how that service should be monitored.

Deploying a sample service

To test monitoring of a service in a user-defined project, you can deploy a sample service.

Procedure

  1. Create a YAML file for the service configuration. In this example, it is called prometheus-example-app.yaml.

  2. Add the following deployment and service configuration details to the file:

    1. apiVersion: v1
    2. kind: Namespace
    3. metadata:
    4.   name: ns1
    5. ---
    6. apiVersion: apps/v1
    7. kind: Deployment
    8. metadata:
    9.   labels:
    10.     app: prometheus-example-app
    11.   name: prometheus-example-app
    12.   namespace: ns1
    13. spec:
    14.   replicas: 1
    15.   selector:
    16.     matchLabels:
    17.       app: prometheus-example-app
    18.   template:
    19.     metadata:
    20.       labels:
    21.         app: prometheus-example-app
    22.     spec:
    23.       containers:
    24.       - image: ghcr.io/rhobs/prometheus-example-app:0.4.1
    25.         imagePullPolicy: IfNotPresent
    26.         name: prometheus-example-app
    27. ---
    28. apiVersion: v1
    29. kind: Service
    30. metadata:
    31.   labels:
    32.     app: prometheus-example-app
    33.   name: prometheus-example-app
    34.   namespace: ns1
    35. spec:
    36.   ports:
    37.   - port: 8080
    38.     protocol: TCP
    39.     targetPort: 8080
    40.     name: web
    41.   selector:
    42.     app: prometheus-example-app
    43.   type: ClusterIP

    This configuration deploys a service named prometheus-example-app in the user-defined ns1 project. This service exposes the custom version metric.

  3. Apply the configuration to the cluster:

    1. $ oc apply -f prometheus-example-app.yaml

    It takes some time to deploy the service.

  4. You can check that the pod is running:

    1. $ oc -n ns1 get pod

    Example output

    1. NAME                                      READY     STATUS    RESTARTS   AGE
    2. prometheus-example-app-7857545cb7-sbgwq   1/1       Running   0          81m

Specifying how a service is monitored

To use the metrics exposed by your service, you must configure OKD monitoring to scrape metrics from the /metrics endpoint. You can do this using a ServiceMonitor custom resource definition (CRD) that specifies how a service should be monitored, or a PodMonitor CRD that specifies how a pod should be monitored. The former requires a Service object, while the latter does not, allowing Prometheus to directly scrape metrics from the metrics endpoint exposed by a pod.

This procedure shows you how to create a ServiceMonitor resource for a service in a user-defined project.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role or the monitoring-edit role.

  • You have enabled monitoring for user-defined projects.

  • For this example, you have deployed the prometheus-example-app sample service in the ns1 project.

    The prometheus-example-app sample service does not support TLS authentication.

Procedure

  1. Create a YAML file for the ServiceMonitor resource configuration. In this example, the file is called example-app-service-monitor.yaml.

  2. Add the following ServiceMonitor resource configuration details:

    1. apiVersion: monitoring.coreos.com/v1
    2. kind: ServiceMonitor
    3. metadata:
    4.   labels:
    5.     k8s-app: prometheus-example-monitor
    6.   name: prometheus-example-monitor
    7.   namespace: ns1
    8. spec:
    9.   endpoints:
    10.   - interval: 30s
    11.     port: web
    12.     scheme: http
    13.   selector:
    14.     matchLabels:
    15.       app: prometheus-example-app

    This defines a ServiceMonitor resource that scrapes the metrics exposed by the prometheus-example-app sample service, which includes the version metric.

    A ServiceMonitor resource in a user-defined namespace can only discover services in the same namespace. That is, the namespaceSelector field of the ServiceMonitor resource is always ignored.

  3. Apply the configuration to the cluster:

    1. $ oc apply -f example-app-service-monitor.yaml

    It takes some time to deploy the ServiceMonitor resource.

  4. You can check that the ServiceMonitor resource is running:

    1. $ oc -n ns1 get servicemonitor

    Example output

    1. NAME                         AGE
    2. prometheus-example-monitor   81m

Additional resources

Querying metrics

The OKD monitoring dashboard enables you to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring.

As a cluster administrator, you can query metrics for all core OKD and user-defined projects.

As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.

Querying metrics for all projects as a cluster administrator

As a cluster administrator or as a user with view permissions for all projects, you can access metrics for all default OKD and user-defined projects in the Metrics UI.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role or with view permissions for all projects.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. Select the Administrator perspective in the OKD web console.

  2. Select Observe → Metrics.

  3. Select Insert Metric at Cursor to view a list of predefined queries.

  4. To create a custom query, add your Prometheus Query Language (PromQL) query to the Expression field.

    As you type a PromQL expression, autocomplete suggestions appear in a drop-down list. These suggestions include functions, metrics, labels, and time tokens. You can use the keyboard arrows to select one of these suggested items and then press Enter to add the item to your expression. You can also move your mouse pointer over a suggested item to view a brief description of that item.

  5. To add multiple queries, select Add Query.

  6. To duplicate an existing query, select kebab next to the query, then choose Duplicate query.

  7. To delete a query, select kebab next to the query, then choose Delete query.

  8. To disable a query from being run, select kebab next to the query and choose Disable query.

  9. To run queries that you created, select Run Queries. The metrics from the queries are visualized on the plot. If a query is invalid, the UI shows an error message.

    Queries that operate on large amounts of data might time out or overload the browser when drawing time series graphs. To avoid this, select Hide graph and calibrate your query using only the metrics table. Then, after finding a feasible query, enable the plot to draw the graphs.

  10. Optional: The page URL now contains the queries you ran. To use this set of queries again in the future, save this URL.

Additional resources

Querying metrics for user-defined projects as a developer

You can access metrics for a user-defined project as a developer or as a user with view permissions for the project.

In the Developer perspective, the Metrics UI includes some predefined CPU, memory, bandwidth, and network packet queries for the selected project. You can also run custom Prometheus Query Language (PromQL) queries for CPU, memory, bandwidth, network packet and application metrics for the project.

Developers can only use the Developer perspective and not the Administrator perspective. As a developer, you can only query metrics for one project at a time in the Observe -→ Metrics page in the web console for your user-defined project.

Prerequisites

  • You have access to the cluster as a developer or as a user with view permissions for the project that you are viewing metrics for.

  • You have enabled monitoring for user-defined projects.

  • You have deployed a service in a user-defined project.

  • You have created a ServiceMonitor custom resource definition (CRD) for the service to define how the service is monitored.

Procedure

  1. Select the Developer perspective in the OKD web console.

  2. Select Observe → Metrics.

  3. Select the project that you want to view metrics for in the Project: list.

  4. Select a query from the Select query list, or create a custom PromQL query based on the selected query by selecting Show PromQL.

  5. Optional: Select Custom query from the Select query list to enter a new query. As you type, autocomplete suggestions appear in a drop-down list. These suggestions include functions and metrics. Click a suggested item to select it.

    In the Developer perspective, you can only run one query at a time.

Additional resources

Exploring the visualized metrics

After running the queries, the metrics are displayed on an interactive plot. The X-axis in the plot represents time and the Y-axis represents metrics values. Each metric is shown as a colored line on the graph. You can manipulate the plot interactively and explore the metrics.

Procedure

In the Administrator perspective:

  1. Initially, all metrics from all enabled queries are shown on the plot. You can select which metrics are shown.

    By default, the query table shows an expanded view that lists every metric and its current value. You can select ˅ to minimize the expanded view for a query.

    • To hide all metrics from a query, click kebab for the query and click Hide all series.

    • To hide a specific metric, go to the query table and click the colored square near the metric name.

  2. To zoom into the plot and change the time range, do one of the following:

    • Visually select the time range by clicking and dragging on the plot horizontally.

    • Use the menu in the left upper corner to select the time range.

  3. To reset the time range, select Reset Zoom.

  4. To display outputs for all queries at a specific point in time, hold the mouse cursor on the plot at that point. The query outputs will appear in a pop-up box.

  5. To hide the plot, select Hide Graph.

In the Developer perspective:

  1. To zoom into the plot and change the time range, do one of the following:

    • Visually select the time range by clicking and dragging on the plot horizontally.

    • Use the menu in the left upper corner to select the time range.

  2. To reset the time range, select Reset Zoom.

  3. To display outputs for all queries at a specific point in time, hold the mouse cursor on the plot at that point. The query outputs will appear in a pop-up box.

Additional resources

Next steps