Overview

Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.

This README describes the necessary configuration to enable collection of OpenShift-specific metrics in the Agent. Data described here are collected by the kubernetes_apiserver check. You must configure the check to collect the openshift.* metrics.

Setup

Installation

This core configuration supports OpenShift 3.11 and OpenShift 4, but it works best with OpenShift 4.

To install the Agent, see the Agent installation instructions for general Kubernetes instructions and the Kubernetes Distributions page for OpenShift configuration examples.

Alternatively, the Datadog Operator can be used to install and manage the Datadog Agent. The Datadog Operator can be installed using OpenShift’s OperatorHub.

Security Context Constraints configuration

If you are deploying the Datadog Agent using any of the methods linked in the installation instructions above, you must include Security Context Constraints (SCCs) for the Agent and Cluster Agent to collect data. Follow the instructions below as they relate to your deployment.

datadog:
  #(...)

agents:
  podSecurity:
    securityContextConstraints:
      create: true

clusterAgent:
  podSecurity:
    securityContextConstraints:
      create: true

ports:
  - containerPort: 8125
    name: dogstatsdport
    protocol: UDP
  - containerPort: 8126
    name: traceport
    protocol: TCP

Custom Datadog SCC for all features

The Helm Chart and Datadog Operator manage the SCC for you by default. To manage it yourself instead, make sure to include the correct configurations based on the features you have enabled.

If SELinux is in permissive mode or disabled, enable the hostaccess SCC to benefit from all features. If SELinux is in enforcing mode, it is recommended to grant the spc_t type to the datadog-agent pod. In order to deploy the agent you can use the following datadog-agent SCC that can be applied after creating the datadog-agent service account. It grants the following permissions:

• allowHostPorts: true: Binds Dogstatsd / APM / Logs intakes to the node’s IP.
• allowHostPID: true: Enables Origin Detection for Dogstatsd metrics submitted by Unix Socket.
• volumes: hostPath: Accesses the Docker socket and the host’s proc and cgroup folders, for metric collection.
• SELinux type: spc_t: Accesses the Docker socket and all processes’ proc and cgroup folders, for metric collection. See Introducing a Super Privileged Container Concept for more details.

Note: The Docker socket is owned by the root group, so you may need to elevate the Agent’s privileges to pull in Docker metrics. To run the Agent process as a root user, you can configure your SCC with the following:

runAsUser:
  type: RunAsAny

Log collection

The Datadog Agent’s log collection is set up in OpenShift largely the same as other Kubernetes clusters. The Datadog Operator and Helm Chart mount in the /var/log/pods directory, which the Datadog Agent pod uses to monitor the logs of the pods and containers on its respective host. However, with the Datadog Operator, you need to apply additional SELinux options to give the Agent permissions to read these log files.

See Kubernetes Log Collection for further general information and the Distributions page for configuration examples.

APM

In Kubernetes, there are three main options to route the data from the application pod to the Datadog Agent pod: the Unix Domain Socket (UDS), the HostIP:HostPort option (TCP/IP), and the Kubernetes Service. The Datadog Operator and Helm Chart default to the UDS option as this is the most resource efficient. However, this option doesn’t work well in OpenShift, as it requires elevated SCC and SELinux options in both the Agent pod and application pod.

Datadog recommends disabling the UDS option explicitly to avoid this, and to avoid the Admission Controller injecting this configuration.

See Kubernetes APM - Trace Collection for further general information and the Distributions page for configuration examples.

Validation

See kubernetes_apiserver

Data Collected

Metrics

Events

The OpenShift check does not include any events.

Service Checks

The OpenShift check does not include any Service Checks.

Troubleshooting

Missing cluster quota metrics

In an OpenShift cluster, most of the Agent and Cluster Agent reported metrics are the same as in other Kubernetes clusters. The only OpenShift-specific metrics are the ones listed above starting with openshift.*. These correspond to the optional OpenShift ClusterResourceQuota objects that you can deploy in your clusters. If you use native Kubernetes ResourceQuotas objects, those are reported by the kubernetes_state_core (KSM) check as kubernetes_state.resourcequota.* metrics.

These OpenShift metrics are reported per active ClusterResourceQuota as part of the Cluster Agent’s kubernetes_apiserver check. For a ClusterResourceQuota to be active, it must be able to identify an OpenShift project (Kubernetes namespace) with the matching label or annotation selectors.

You can confirm that these resources exist by running oc get clusterresourcequotas. Then, run oc describe clusterresourcequotas <NAME> to check whether a quota is active. An active quota looks like:

$ oc describe clusterresourcequota example-cluster-quota
Name: example-cluster-quota
Created: 2 weeks ago
Labels: <none>
Annotations: <none>
Namespace Selector: []
Label Selector:
AnnotationSelector: map[example-annotation:value]
Resource Used Hard
-------- ---- ----
pods      1     10
secrets   9     20

In the example above, metrics for this quota are reported only for pod and secret usage. As you apply quotas to different resources like CPU, storage, ConfigMaps, the corresponding usage metrics are reported.

If your ClusterResourceQuota describe output does not show any resources or their Used/Hard values, the quota is not actively applied by its selectors. No data is reported for these non-active quotas.

Need help? Contact Datadog support.