Chapter 4. Configuring the instrumentation


Important

OpenTelemetry instrumentation injection is 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.

The Red Hat build of OpenTelemetry Operator uses a custom resource definition (CRD) file that defines the configuration of the instrumentation.

4.1. OpenTelemetry instrumentation configuration options

The Red Hat build of OpenTelemetry can inject and configure the OpenTelemetry auto-instrumentation libraries into your workloads. Currently, the project supports injection of the instrumentation libraries from Go, Java, Node.js, Python, .NET, and the Apache HTTP Server (httpd).

Auto-instrumentation in OpenTelemetry refers to the capability where the framework automatically instruments an application without manual code changes. This enables developers and administrators to get observability into their applications with minimal effort and changes to the existing codebase.

Important

The Red Hat build of OpenTelemetry Operator only supports the injection mechanism of the instrumentation libraries but does not support instrumentation libraries or upstream images. Customers can build their own instrumentation images or use community images.

4.1.1. Instrumentation options

Instrumentation options are specified in an Instrumentation custom resource (CR).

Sample Instrumentation CR

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: java-instrumentation
spec:
  env:
    - name: OTEL_EXPORTER_OTLP_TIMEOUT
      value: "20"
  exporter:
    endpoint: http://production-collector.observability.svc.cluster.local:4317
  propagators:
    - w3c
  sampler:
    type: parentbased_traceidratio
    argument: "0.25"
  java:
    env:
    - name: OTEL_JAVAAGENT_DEBUG
      value: "true"

Table 4.1. Parameters used by the Operator to define the Instrumentation
ParameterDescriptionValues

env

Common environment variables to define across all the instrumentations.

 

exporter

Exporter configuration.

 

propagators

Propagators defines inter-process context propagation configuration.

tracecontext, baggage, b3, b3multi, jaeger, ottrace, none

resource

Resource attributes configuration.

 

sampler

Sampling configuration.

 

apacheHttpd

Configuration for the Apache HTTP Server instrumentation.

 

dotnet

Configuration for the .NET instrumentation.

 

go

Configuration for the Go instrumentation.

 

java

Configuration for the Java instrumentation.

 

nodejs

Configuration for the Node.js instrumentation.

 

python

Configuration for the Python instrumentation.

 

4.1.2. Configuration of the Apache HTTP Server auto-instrumentation

Table 4.2. Parameters for the .spec.apacheHttpd field
NameDescriptionDefault

attrs

Attributes specific to the Apache HTTP Server.

 

configPath

Location of the Apache HTTP Server configuration.

/usr/local/apache2/conf

env

Environment variables specific to the Apache HTTP Server.

 

image

Container image with the Apache SDK and auto-instrumentation.

 

resourceRequirements

The compute resource requirements.

 

version

Apache HTTP Server version.

2.4

The PodSpec annotation to enable injection

instrumentation.opentelemetry.io/inject-apache-httpd: "true"

4.1.3. Configuration of the .NET auto-instrumentation

NameDescription

env

Environment variables specific to .NET.

image

Container image with the .NET SDK and auto-instrumentation.

resourceRequirements

The compute resource requirements.

For the .NET auto-instrumentation, the required OTEL_EXPORTER_OTLP_ENDPOINT environment variable must be set if the endpoint of the exporters is set to 4317. The .NET autoinstrumentation uses http/proto by default, and the telemetry data must be set to the 4318 port.

The PodSpec annotation to enable injection

instrumentation.opentelemetry.io/inject-dotnet: "true"

4.1.4. Configuration of the Go auto-instrumentation

NameDescription

env

Environment variables specific to Go.

image

Container image with the Go SDK and auto-instrumentation.

resourceRequirements

The compute resource requirements.

The PodSpec annotation to enable injection

instrumentation.opentelemetry.io/inject-go: "true"

Additional permissions required for the Go auto-instrumentation in the OpenShift cluster

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: otel-go-instrumentation-scc
allowHostDirVolumePlugin: true
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
- "SYS_PTRACE"
fsGroup:
  type: RunAsAny
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups:
  type: RunAsAny

Tip

The CLI command for applying the permissions for the Go auto-instrumentation in the OpenShift cluster is as follows:

$ oc adm policy add-scc-to-user otel-go-instrumentation-scc -z <service_account>

4.1.5. Configuration of the Java auto-instrumentation

NameDescription

env

Environment variables specific to Java.

image

Container image with the Java SDK and auto-instrumentation.

resourceRequirements

The compute resource requirements.

The PodSpec annotation to enable injection

instrumentation.opentelemetry.io/inject-java: "true"

4.1.6. Configuration of the Node.js auto-instrumentation

NameDescription

env

Environment variables specific to Node.js.

image

Container image with the Node.js SDK and auto-instrumentation.

resourceRequirements

The compute resource requirements.

The PodSpec annotations to enable injection

instrumentation.opentelemetry.io/inject-nodejs: "true"
instrumentation.opentelemetry.io/otel-go-auto-target-exe: "/path/to/container/executable"

The instrumentation.opentelemetry.io/otel-go-auto-target-exe annotation sets the value for the required OTEL_GO_AUTO_TARGET_EXE environment variable.

4.1.7. Configuration of the Python auto-instrumentation

NameDescription

env

Environment variables specific to Python.

image

Container image with the Python SDK and auto-instrumentation.

resourceRequirements

The compute resource requirements.

For Python auto-instrumentation, the OTEL_EXPORTER_OTLP_ENDPOINT environment variable must be set if the endpoint of the exporters is set to 4317. Python auto-instrumentation uses http/proto by default, and the telemetry data must be set to the 4318 port.

The PodSpec annotation to enable injection

instrumentation.opentelemetry.io/inject-python: "true"

4.1.8. Configuration of the OpenTelemetry SDK variables

The OpenTelemetry SDK variables in your pod are configurable by using the following annotation:

instrumentation.opentelemetry.io/inject-sdk: "true"

Note that all the annotations accept the following values:

true
Injects the Instrumentation resource from the namespace.
false
Does not inject any instrumentation.
instrumentation-name
The name of the instrumentation resource to inject from the current namespace.
other-namespace/instrumentation-name
The name of the instrumentation resource to inject from another namespace.

4.1.9. Multi-container pods

The instrumentation is run on the first container that is available by default according to the pod specification. In some cases, you can also specify target containers for injection.

Pod annotation

instrumentation.opentelemetry.io/container-names: "<container_1>,<container_2>"

Note

The Go auto-instrumentation does not support multi-container auto-instrumentation injection.

4.1.10. Using the instrumentation CR with Service Mesh

When using the instrumentation custom resource (CR) with Red Hat OpenShift Service Mesh, you must use the b3multi propagator.

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.

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.

© 2024 Red Hat, Inc.