ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.3

OpenTelemetry Operator for Kubernetes

OpenTelemetry Operator 是 Kubernetes Operator 的一种实现。

该 Operator 管理以下内容：

• https://github.com/open-telemetry/opentelemetry-collector
• 使用 OpenTelemetry instrumentation 库对工作负载进行的 自动 instrumentation

文档

• 兼容性与支持文档
• API 文档
• OpenTelemetry Operator 官方页面

Helm 图表

您可以通过 opentelemetry-helm-charts 仓库中的 https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator 安装 OpenTelemetry Operator。更多信息请参见 https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator%E3%80%82

快速开始

要在现有集群中安装 Operator，请确保已安装 cert-manager，然后运行：

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

当 opentelemetry-operator 部署就绪后，创建 OpenTelemetry Collector（otelcol）实例，例如：

kubectl apply -f -

[!NOTE] 此时，Operator 不会验证配置文件的全部内容：如果配置无效，实例可能仍会创建，但底层的 OpenTelemetry Collector 可能会崩溃。

Operator 会出于以下几个目的检查配置文件：

• 发现已配置的接收器及其端口。如果发现带有端口的接收器，它会创建一对 Kubernetes 服务（一个无头服务），在集群内公开这些端口。如果端口使用环境变量扩展或无法解析，将返回错误。无头服务包含 service.beta.openshift.io/serving-cert-secret-name 注解，该注解会使 OpenShift 创建包含证书和密钥的密钥。此密钥可以作为卷挂载，并在这些接收器的 TLS 配置中使用证书和密钥。

• 检查是否启用了 Collector 可观测性（由 spec.observability.metrics.enableMetrics 控制）。在这种情况下，会为 Collector 实例创建 Service 和 ServiceMonitor/PodMonitor。因此，如果指标服务地址包含无效端口或对端口使用环境变量扩展，将返回错误。环境变量情况下的解决方法是将 enableMetrics 设置为 false，如果需要，可以手动创建上述带有正确端口的对象。

升级

如上所述，OpenTelemetry Collector 格式仍在不断发展。不过，我们会尽最大努力升级所有受管理的 OpenTelemetryCollector 资源。

在某些情况下，可能需要阻止 Operator 升级某些 OpenTelemetryCollector 资源。例如，当资源配置了自定义 .Spec.Image 时，最终用户可能希望自己管理配置，而不是由 Operator 进行升级。可以通过公开的 .Spec.UpgradeStrategy 属性为每个资源单独配置。

通过将资源的 .Spec.UpgradeStrategy 配置为 none，Operator 会在升级过程中跳过该实例。

.Spec.UpgradeStrategy 的默认值和唯一其他可接受值是 automatic。

部署模式

以下是每种部署模式的示例：

• Deployment
• DaemonSet
• StatefulSet
• Sidecar

边车注入

通过将 Pod 注解 sidecar.opentelemetry.io/inject 设置为 "true" 或具体的 OpenTelemetryCollector 名称，可以将带有 OpenTelemetry Collector 的边车注入基于 Pod 的工作负载，如下例所示：

kubectl apply -f -

• 创建 imagePullSecret。

kubectl create secret docker-registry --docker-server= \
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
--docker-email=DUMMY_DOCKER_EMAIL

• 向服务账户添加镜像拉取密钥

kubectl patch serviceaccount -p '{"imagePullSecrets": [{"name": " "}]}'

OpenTelemetry 自动 instrumentation 注入

Operator 可以注入和配置 OpenTelemetry 自动 instrumentation 库。目前支持 Apache HTTPD、DotNet、Go、Java、Nginx、NodeJS 和 Python。

要使用自动 instrumentation，请配置 Instrumentation 资源，包含 SDK 和 instrumentation 的配置。

kubectl apply -f -

[!NOTE] 对于 DotNet 自动 instrumentation，默认情况下，Operator 会设置 OTEL_DOTNET_AUTO_TRACES_ENABLED_INSTRUMENTATIONS 环境变量，该变量指定要启用的跟踪源 instrumentation 列表。Operator 默认设置的值是镜像中包含的 openTelemery-dotnet-instrumentation 版本支持的所有可用 instrumentation，即 AspNet,HttpClient,SqlClient。可以通过显式配置该环境变量来覆盖此值。

具有单一 instrumentation 的多容器 Pod

如果未指定其他内容，instrumentation 会在 Pod 规范中第一个可用的容器（来自 .spec.containers，而非 init 容器）上执行。在某些情况下（例如注入 Istio 边车时），需要指定必须在哪些容器上执行此注入。

为此，可以微调要执行注入的 Pod。

为此，我们将使用 instrumentation.opentelemetry.io/container-names 注解，在该注解中指定一个或多个必须进行注入的容器名称（来自 .spec.containers.name 或 .spec.initContainers.name）：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-multiple-containers
spec:
selector:
matchLabels:
app: my-pod-with-multiple-containers
replicas: 1
template:
metadata:
labels:
app: my-pod-with-multiple-containers
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
instrumentation.opentelemetry.io/container-names: "myapp,myapp2"
spec:
containers:
- name: myapp
image: myImage1
- name: myapp2
image: myImage2
- name: myapp3
image: myImage3

在上述情况下，myapp 和 myapp2 容器将被 instrumentation，myapp3 则不会。

为 Init 容器注入 instrumentation

可以通过在 container-names 注解中包含 Init 容器的名称来为其注入 instrumentation。当某个 Init 容器被指定为注入目标时，operator 会在 Pod 的 Init 容器序列中，自动将 instrumentation Init 容器插入到目标 Init 容器之前。这样可以确保目标 Init 容器运行时，instrumentation 代理文件已准备就绪。

支持为 Init 容器注入的 instrumentation：

• Java
• Python
• Node.js
• .NET
• 仅 SDK 注入

不支持为 Init 容器注入的 instrumentation：

• Go（不支持多容器 Pod）
• Apache HTTPD
• Nginx

[!NOTE] Kubernetes 保证在 Pod 规范的 initContainers 和 containers 列表中，容器名称是唯一的。这使得 operator 能够明确识别容器名称是指向 Init 容器还是常规容器。

同时为 Init 容器和常规容器注入 instrumentation 的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-init-container
spec:
selector:
matchLabels:
app: my-app
replicas: 1
template:
metadata:
labels:
app: my-app
annotations:
instrumentation.opentelemetry.io/inject-python: "true"
instrumentation.opentelemetry.io/container-names: "my-init-job,myapp"
spec:
initContainers:
- name: my-init-job
image: my-python-init-image
containers:
- name: myapp
image: my-python-app-image

在此示例中，my-init-job（Init 容器）和 myapp（常规容器）都将通过 Python 自动 instrumentation 进行注入。

具有多种 instrumentation 的多容器 Pod

仅当 enable-multi-instrumentation 标志设为 true 时才生效。

需要通过注解指定要注入的语言 instrumentation。启用此功能后，将使用特定于 instrumentation 语言的容器注解（这些注解也支持为 Java、Python、Node.js、.NET 和 SDK 指定 Init 容器名称）：

Java：

instrumentation.opentelemetry.io/java-container-names: "java1,java2"

NodeJS：

instrumentation.opentelemetry.io/nodejs-container-names: "nodejs1,nodejs2"

Python：

instrumentation.opentelemetry.io/python-container-names: "python1,python3"

DotNet：

instrumentation.opentelemetry.io/dotnet-container-names: "dotnet1,dotnet2"

Go：

instrumentation.opentelemetry.io/go-container-names: "go1"

ApacheHttpD：

instrumentation.opentelemetry.io/apache-httpd-container-names: "apache1,apache2"

NGINX：

instrumentation.opentelemetry.io/inject-nginx-container-names: "nginx1,nginx2"

SDK：

instrumentation.opentelemetry.io/sdk-container-names: "app1,app2"

如果未指定特定于语言 instrumentation 的容器名称，则会对 Pod 规范中第一个可用的常规容器执行 instrumentation（仅在配置了单一 instrumentation 注入时）。

在某些情况下，Pod 中的容器使用不同的技术。此时需要为必须执行注入的容器指定语言 instrumentation。

为此，我们将使用特定于语言 instrumentation 的容器名称注解，在其中指定一个或多个必须执行注入的容器名称（.spec.containers.name 或 .spec.initContainers.name）：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-multi-containers-multi-instrumentations
spec:
selector:
matchLabels:
app: my-pod-with-multi-containers-multi-instrumentations
replicas: 1
template:
metadata:
labels:
app: my-pod-with-multi-containers-multi-instrumentations
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
instrumentation.opentelemetry.io/java-container-names: "myapp,myapp2"
instrumentation.opentelemetry.io/inject-python: "true"
instrumentation.opentelemetry.io/python-container-names: "myapp3"
spec:
containers:
- name: myapp
image: myImage1
- name: myapp2
image: myImage2
- name: myapp3
image: myImage3

在上述情况下，myapp 和 myapp2 容器将使用 Java instrumentation 进行注入，myapp3 将使用 Python instrumentation 进行注入。

[!NOTE] Go 自动 instrumentation 不 支持多容器 Pod。注入 Go 自动 instrumentation 时，第一个容器应是唯一需要注入的容器。

[!NOTE] 此类 instrumentation 不 允许为一个容器注入多种语言的 instrumentation。

[!NOTE] instrumentation.opentelemetry.io/container-names 注解不用于此功能。

使用自定义或供应商 instrumentation

默认情况下，operator 使用上游自动 instrumentation 库。可以通过覆盖 CR 中的 image 字段来配置自定义自动 instrumentation。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: my-instrumentation
spec:
java:
image: your-customized-auto-instrumentation-image:java
nodejs:
image: your-customized-auto-instrumentation-image:nodejs
python:
image: your-customized-auto-instrumentation-image:python
dotnet:
image: your-customized-auto-instrumentation-image:dotnet
go:
image: your-customized-auto-instrumentation-image:go
apacheHttpd:
image: your-customized-auto-instrumentation-image:apache-httpd
nginx:
image: your-customized-auto-instrumentation-image:nginx

自动 instrumentation 的 Dockerfile 可在 autoinstrumentation 目录 中找到。请按照 Dockerfile 中的说明构建自定义容器镜像。

使用 Apache HTTPD 自动 instrumentation

对于 Apache HTTPD 自动 instrumentation，默认情况下，instrumentation 假设使用 httpd 2.4 版本，且 httpd 配置目录为 /usr/local/apache2/conf（与官方 Apache HTTPD 镜像一致，例如 docker.io/httpd:latest）。如果需要使用 2.2 版本，或 HTTPD 配置目录不同，或需要调整代理属性，请按照以下示例自定义 instrumentation 规范：

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: my-instrumentation
spec:
apacheHttpd:
image: your-customized-auto-instrumentation-image:apache-httpd
version: "2.2"
configPath: /your-custom-config-path
attrs:
- name: ApacheModuleOtelMaxQueueSize
value: "4096"
- name: ...
value: ...

所有可用属性的列表可在 https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/otel-webserver-module 中找到。

使用 Nginx 自动 instrumentation

仅注入 OpenTelemetry SDK 环境变量

对于目前无法自动插桩的应用程序，你可以通过使用 inject-sdk 替代 inject-python 或 inject-java 来配置 OpenTelemetry SDK。这将注入环境变量，例如 OTEL_RESOURCE_ATTRIBUTES、OTEL_TRACES_SAMPLER 和 OTEL_EXPORTER_OTLP_ENDPOINT，你可以在 Instrumentation 中配置这些变量，但不会实际提供 SDK。

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

控制插桩功能

操作员允许通过标志指定 Instrumentation 资源可以插桩的语言。如果某种语言默认启用，则仅在禁用该语言的开关时才需要提供其开关。可以通过传递值为 false 的标志来禁用语言支持。

OpenTelemetry Operator 允许使用多种特定语言的插桩工具对多个容器进行插桩。可以通过 enable-multi-instrumentation 标志启用这些功能。该标志默认值为 false。

有关多插桩功能的更多信息，请参见 多容器 Pod 与多插桩。

目标分配器

OpenTelemetry Operator 附带一个可选组件：目标分配器（TA）。创建 OpenTelemetryCollector 自定义资源（CR）并将 TA 设置为启用状态时，操作员将创建新的部署和服务，为该 CR 中的每个 Collector pod 提供特定的 http_sd_config 指令。它还会重写 CR 中的 Prometheus 接收器配置，以使其使用已部署的目标分配器。以下示例展示了如何开始使用目标分配器：

kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
name: collector-with-ta
spec:
mode: statefulset
targetAllocator:
enabled: true
config:
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: [ '0.0.0.0:8888' ]
metric_relabel_configs:
- action: labeldrop
regex: (id|name)
- action: labelmap
regex: label_(.+)
replacement: $1

exporters:
debug: {}

service:
pipelines:
metrics:
receivers: [prometheus]
exporters: [debug]
EOF

上述示例中替换键中 `# OpenTelemetry Operator for Kubernetes

OpenTelemetry Operator 是 Kubernetes Operator 的一种实现。

该 Operator 管理以下内容：

• https://github.com/open-telemetry/opentelemetry-collector
• 使用 OpenTelemetry instrumentation 库对工作负载进行的 自动 instrumentation

文档

• 兼容性与支持文档
• API 文档
• OpenTelemetry Operator 官方页面

Helm 图表

您可以通过 opentelemetry-helm-charts 仓库中的 https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator 安装 OpenTelemetry Operator。更多信息请参见 https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator%E3%80%82

快速开始

要在现有集群中安装 Operator，请确保已安装 cert-manager，然后运行：

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

当 opentelemetry-operator 部署就绪后，创建 OpenTelemetry Collector（otelcol）实例，例如：

kubectl apply -f -

[!NOTE] 此时，Operator 不会验证配置文件的全部内容：如果配置无效，实例可能仍会创建，但底层的 OpenTelemetry Collector 可能会崩溃。

Operator 会出于以下几个目的检查配置文件：

• 发现已配置的接收器及其端口。如果发现带有端口的接收器，它会创建一对 Kubernetes 服务（一个无头服务），在集群内公开这些端口。如果端口使用环境变量扩展或无法解析，将返回错误。无头服务包含 service.beta.openshift.io/serving-cert-secret-name 注解，该注解会使 OpenShift 创建包含证书和密钥的密钥。此密钥可以作为卷挂载，并在这些接收器的 TLS 配置中使用证书和密钥。

• 检查是否启用了 Collector 可观测性（由 spec.observability.metrics.enableMetrics 控制）。在这种情况下，会为 Collector 实例创建 Service 和 ServiceMonitor/PodMonitor。因此，如果指标服务地址包含无效端口或对端口使用环境变量扩展，将返回错误。环境变量情况下的解决方法是将 enableMetrics 设置为 false，如果需要，可以手动创建上述带有正确端口的对象。

升级

如上所述，OpenTelemetry Collector 格式仍在不断发展。不过，我们会尽最大努力升级所有受管理的 OpenTelemetryCollector 资源。

在某些情况下，可能需要阻止 Operator 升级某些 OpenTelemetryCollector 资源。例如，当资源配置了自定义 .Spec.Image 时，最终用户可能希望自己管理配置，而不是由 Operator 进行升级。可以通过公开的 .Spec.UpgradeStrategy 属性为每个资源单独配置。

通过将资源的 .Spec.UpgradeStrategy 配置为 none，Operator 会在升级过程中跳过该实例。

.Spec.UpgradeStrategy 的默认值和唯一其他可接受值是 automatic。

部署模式

以下是每种部署模式的示例：

• Deployment
• DaemonSet
• StatefulSet
• Sidecar

边车注入

通过将 Pod 注解 sidecar.opentelemetry.io/inject 设置为 "true" 或具体的 OpenTelemetryCollector 名称，可以将带有 OpenTelemetry Collector 的边车注入基于 Pod 的工作负载，如下例所示：

kubectl apply -f -

• 创建 imagePullSecret。

kubectl create secret docker-registry --docker-server= \
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
--docker-email=DUMMY_DOCKER_EMAIL

• 向服务账户添加镜像拉取密钥

kubectl patch serviceaccount -p '{"imagePullSecrets": [{"name": " "}]}'

OpenTelemetry 自动 instrumentation 注入

Operator 可以注入和配置 OpenTelemetry 自动 instrumentation 库。目前支持 Apache HTTPD、DotNet、Go、Java、Nginx、NodeJS 和 Python。

要使用自动 instrumentation，请配置 Instrumentation 资源，包含 SDK 和 instrumentation 的配置。

kubectl apply -f -

[!NOTE] 对于 DotNet 自动 instrumentation，默认情况下，Operator 会设置 OTEL_DOTNET_AUTO_TRACES_ENABLED_INSTRUMENTATIONS 环境变量，该变量指定要启用的跟踪源 instrumentation 列表。Operator 默认设置的值是镜像中包含的 openTelemery-dotnet-instrumentation 版本支持的所有可用 instrumentation，即 AspNet,HttpClient,SqlClient。可以通过显式配置该环境变量来覆盖此值。

具有单一 instrumentation 的多容器 Pod

如果未指定其他内容，instrumentation 会在 Pod 规范中第一个可用的容器（来自 .spec.containers，而非 init 容器）上执行。在某些情况下（例如注入 Istio 边车时），需要指定必须在哪些容器上执行此注入。

为此，可以微调要执行注入的 Pod。

为此，我们将使用 instrumentation.opentelemetry.io/container-names 注解，在该注解中指定一个或多个必须进行注入的容器名称（来自 .spec.containers.name 或 .spec.initContainers.name）：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-multiple-containers
spec:
selector:
matchLabels:
app: my-pod-with-multiple-containers
replicas: 1
template:
metadata:
labels:
app: my-pod-with-multiple-containers
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
instrumentation.opentelemetry.io/container-names: "myapp,myapp2"
spec:
containers:
- name: myapp
image: myImage1
- name: myapp2
image: myImage2
- name: myapp3
image: myImage3

在上述情况下，myapp 和 myapp2 容器将被 instrumentation，myapp3 则不会。

为 Init 容器注入 instrumentation

可以通过在 container-names 注解中包含 Init 容器的名称来为其注入 instrumentation。当某个 Init 容器被指定为注入目标时，operator 会在 Pod 的 Init 容器序列中，自动将 instrumentation Init 容器插入到目标 Init 容器之前。这样可以确保目标 Init 容器运行时，instrumentation 代理文件已准备就绪。

支持为 Init 容器注入的 instrumentation：

• Java
• Python
• Node.js
• .NET
• 仅 SDK 注入

不支持为 Init 容器注入的 instrumentation：

• Go（不支持多容器 Pod）
• Apache HTTPD
• Nginx

[!NOTE] Kubernetes 保证在 Pod 规范的 initContainers 和 containers 列表中，容器名称是唯一的。这使得 operator 能够明确识别容器名称是指向 Init 容器还是常规容器。

同时为 Init 容器和常规容器注入 instrumentation 的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-init-container
spec:
selector:
matchLabels:
app: my-app
replicas: 1
template:
metadata:
labels:
app: my-app
annotations:
instrumentation.opentelemetry.io/inject-python: "true"
instrumentation.opentelemetry.io/container-names: "my-init-job,myapp"
spec:
initContainers:
- name: my-init-job
image: my-python-init-image
containers:
- name: myapp
image: my-python-app-image

在此示例中，my-init-job（Init 容器）和 myapp（常规容器）都将通过 Python 自动 instrumentation 进行注入。

具有多种 instrumentation 的多容器 Pod

仅当 enable-multi-instrumentation 标志设为 true 时才生效。

需要通过注解指定要注入的语言 instrumentation。启用此功能后，将使用特定于 instrumentation 语言的容器注解（这些注解也支持为 Java、Python、Node.js、.NET 和 SDK 指定 Init 容器名称）：

Java：

instrumentation.opentelemetry.io/java-container-names: "java1,java2"

NodeJS：

instrumentation.opentelemetry.io/nodejs-container-names: "nodejs1,nodejs2"

Python：

instrumentation.opentelemetry.io/python-container-names: "python1,python3"

DotNet：

instrumentation.opentelemetry.io/dotnet-container-names: "dotnet1,dotnet2"

Go：

instrumentation.opentelemetry.io/go-container-names: "go1"

ApacheHttpD：

instrumentation.opentelemetry.io/apache-httpd-container-names: "apache1,apache2"

NGINX：

instrumentation.opentelemetry.io/inject-nginx-container-names: "nginx1,nginx2"

SDK：

instrumentation.opentelemetry.io/sdk-container-names: "app1,app2"

如果未指定特定于语言 instrumentation 的容器名称，则会对 Pod 规范中第一个可用的常规容器执行 instrumentation（仅在配置了单一 instrumentation 注入时）。

在某些情况下，Pod 中的容器使用不同的技术。此时需要为必须执行注入的容器指定语言 instrumentation。

为此，我们将使用特定于语言 instrumentation 的容器名称注解，在其中指定一个或多个必须执行注入的容器名称（.spec.containers.name 或 .spec.initContainers.name）：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment-with-multi-containers-multi-instrumentations
spec:
selector:
matchLabels:
app: my-pod-with-multi-containers-multi-instrumentations
replicas: 1
template:
metadata:
labels:
app: my-pod-with-multi-containers-multi-instrumentations
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
instrumentation.opentelemetry.io/java-container-names: "myapp,myapp2"
instrumentation.opentelemetry.io/inject-python: "true"
instrumentation.opentelemetry.io/python-container-names: "myapp3"
spec:
containers:
- name: myapp
image: myImage1
- name: myapp2
image: myImage2
- name: myapp3
image: myImage3

在上述情况下，myapp 和 myapp2 容器将使用 Java instrumentation 进行注入，myapp3 将使用 Python instrumentation 进行注入。

[!NOTE] Go 自动 instrumentation 不 支持多容器 Pod。注入 Go 自动 instrumentation 时，第一个容器应是唯一需要注入的容器。

[!NOTE] 此类 instrumentation 不 允许为一个容器注入多种语言的 instrumentation。

[!NOTE] instrumentation.opentelemetry.io/container-names 注解不用于此功能。

使用自定义或供应商 instrumentation

默认情况下，operator 使用上游自动 instrumentation 库。可以通过覆盖 CR 中的 image 字段来配置自定义自动 instrumentation。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: my-instrumentation
spec:
java:
image: your-customized-auto-instrumentation-image:java
nodejs:
image: your-customized-auto-instrumentation-image:nodejs
python:
image: your-customized-auto-instrumentation-image:python
dotnet:
image: your-customized-auto-instrumentation-image:dotnet
go:
image: your-customized-auto-instrumentation-image:go
apacheHttpd:
image: your-customized-auto-instrumentation-image:apache-httpd
nginx:
image: your-customized-auto-instrumentation-image:nginx

自动 instrumentation 的 Dockerfile 可在 autoinstrumentation 目录 中找到。请按照 Dockerfile 中的说明构建自定义容器镜像。

使用 Apache HTTPD 自动 instrumentation

对于 Apache HTTPD 自动 instrumentation，默认情况下，instrumentation 假设使用 httpd 2.4 版本，且 httpd 配置目录为 /usr/local/apache2/conf（与官方 Apache HTTPD 镜像一致，例如 docker.io/httpd:latest）。如果需要使用 2.2 版本，或 HTTPD 配置目录不同，或需要调整代理属性，请按照以下示例自定义 instrumentation 规范：

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: my-instrumentation
spec:
apacheHttpd:
image: your-customized-auto-instrumentation-image:apache-httpd
version: "2.2"
configPath: /your-custom-config-path
attrs:
- name: ApacheModuleOtelMaxQueueSize
value: "4096"
- name: ...
value: ...

所有可用属性的列表可在 https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/otel-webserver-module 中找到。

使用 Nginx 自动 instrumentation

仅注入 OpenTelemetry SDK 环境变量

对于目前无法自动插桩的应用程序，你可以通过使用 inject-sdk 替代 inject-python 或 inject-java 来配置 OpenTelemetry SDK。这将注入环境变量，例如 OTEL_RESOURCE_ATTRIBUTES、OTEL_TRACES_SAMPLER 和 OTEL_EXPORTER_OTLP_ENDPOINT，你可以在 Instrumentation 中配置这些变量，但不会实际提供 SDK。

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

控制插桩功能

操作员允许通过标志指定 Instrumentation 资源可以插桩的语言。如果某种语言默认启用，则仅在禁用该语言的开关时才需要提供其开关。可以通过传递值为 false 的标志来禁用语言支持。

OpenTelemetry Operator 允许使用多种特定语言的插桩工具对多个容器进行插桩。可以通过 enable-multi-instrumentation 标志启用这些功能。该标志默认值为 false。

有关多插桩功能的更多信息，请参见 多容器 Pod 与多插桩。

目标分配器

OpenTelemetry Operator 附带一个可选组件：目标分配器（TA）。创建 OpenTelemetryCollector 自定义资源（CR）并将 TA 设置为启用状态时，操作员将创建新的部署和服务，为该 CR 中的每个 Collector pod 提供特定的 http_sd_config 指令。它还会重写 CR 中的 Prometheus 接收器配置，以使其使用已部署的目标分配器。以下示例展示了如何开始使用目标分配器：

kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
name: collector-with-ta
spec:
mode: statefulset
targetAllocator:
enabled: true
config:
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: [ '0.0.0.0:8888' ]
metric_relabel_configs:
- action: labeldrop
regex: (id|name)
- action: labelmap
regex: label_(.+)
replacement: $1

exporters:
debug: {}

service:
pipelines:
metrics:
receivers: [prometheus]
exporters: [debug]
EOF

上述示例中替换键中 的使用基于 Prometheus 接收器 https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/README.md 文档中提供的信息，该文档指出：
注意：由于收集器配置支持环境变量替换，因此 Prometheus 配置中的 $ 字符会被解释为环境变量。如果要在 Prometheus 配置中使用 $ 字符，必须使用 $ 对其进行转义。

在幕后，OpenTelemetry Operator 会在调和后将收集器的配置转换为以下内容：

receivers:
prometheus:
target_allocator:
endpoint: http://collector-with-ta-targetallocator:80
interval: 30s
collector_id: $POD_NAME

exporters:
debug:

service:
pipelines:
metrics:
receivers: [prometheus]
exporters: [debug]

OpenTelemetry Operator 还会在调和后将目标分配器的 Prometheus 配置转换为以下内容：

config:
scrape_configs:
- job_name: otel-collector
scrape_interval: 10s
static_configs:
- targets: ["0.0.0.0:8888"]
metric_relabel_configs:
- action: labeldrop
regex: (id|name)
- action: labelmap
regex: label_(.+)
replacement: $1

请注意，在这种情况下，操作员会将替换键中的 "$$" 替换为单个 "$"。这是因为收集器支持环境变量替换，而 TA（目标分配器）不支持。因此，为确保兼容性，TA 配置应仅包含单个 "$" 符号。

有关 TargetAllocator 的更多信息，请参见 此处。

使用 Prometheus 自定义资源进行服务发现

目标分配器可以使用 prometheus-operator 生态系统中的自定义资源（如 ServiceMonitor 和 PodMonitor）进行服务发现，执行与 prometheus-operator 本身类似的功能。这通过 Collector CR 中的 prometheusCR 部分启用。

以下是一个最小示例：

kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
name: collector-with-ta-prometheus-cr
spec:
mode: statefulset
targetAllocator:
enabled: true
serviceAccount: everything-prometheus-operator-needs
prometheusCR:
enabled: true
serviceMonitorSelector: {}
podMonitorSelector: {}
scrapeClasses: []
config:
receivers:
prometheus:
config: {}

exporters:
debug: {}

service:
pipelines:
metrics:
receivers: [prometheus]
exporters: [debug]
EOF

scrapeClasses 属性引用 Prometheus Operator 的 ScrapeClass 功能。有关抓取类的更多信息，请参阅 [***]

设置资源属性的优先级

设置资源属性的优先级如下（找到的第一个值生效）：

1. 通过 OTEL_RESOURCE_ATTRIBUTES 和 OTEL_SERVICE_NAME 环境变量设置的资源属性
2. 通过注解（带有 resource.opentelemetry.io/ 前缀）设置的资源属性
3. 通过标签（例如 app.kubernetes.io/name）设置的资源属性（如果 Instrumentation CR 的 defaults.useLabelsForResourceAttributes=true，见上文）
4. 从 Pod 元数据计算的资源属性（例如 k8s.pod.name）
5. 通过 Instrumentation CR（在 spec.resource.resourceAttributes 部分）设置的资源属性

此优先级对每个资源属性单独应用，因此可以通过注解设置某些属性，通过标签设置其他属性。

如何从 Pod 元数据计算资源属性

以下资源属性是从 Pod 的元数据计算得出的。

service.name 的计算方式

选择找到的第一个值：

• pod.annotation[resource.opentelemetry.io/service.name]
• if (config[useLabelsForResourceAttributes]) pod.label[app.kubernetes.io/name]
• k8s.deployment.name
• k8s.replicaset.name
• k8s.statefulset.name
• k8s.daemonset.name
• k8s.cronjob.name
• k8s.job.name
• k8s.pod.name
• k8s.container.name

service.version 的计算方式

选择找到的第一个值：

• pod.annotation[resource.opentelemetry.io/service.version]
• if (cfg[useLabelsForResourceAttributes]) pod.label[app.kubernetes.io/version]
• if (contains(container docker image tag, '/') == false) container docker image tag

service.instance.id 的计算方式

选择找到的第一个值：

• pod.annotation[resource.opentelemetry.io/service.instance.id]
• concat([k8s.namespace.name, k8s.pod.name, k8s.container.name], '.')

service.namespace 的计算方式

选择找到的第一个值：

• pod.annotation[resource.opentelemetry.io/service.namespace]
• k8s.namespace.name