专属域名
文档搜索
轩辕助手
Run助手
邀请有礼
返回顶部
快速返回页面顶部
收起
收起工具栏
轩辕镜像 官方专业版
轩辕镜像
专业版
轩辕镜像 官方专业版
轩辕镜像
专业版
首页个人中心搜索镜像

交易
充值流量我的订单
工具
提交工单镜像收录一键安装
Npm 源Pip 源Homebrew 源
帮助
常见问题轩辕镜像免费版
其他
关于我们网站地图
热门搜索:
ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd

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

ghcr.iolinux/amd641.0.2大小: 未知更新于 2026年5月23日

Kubernetes 的 OpenTelemetry Operator

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）实例，例如：

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

Operator 会检查配置文件以实现以下几个目的：

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

部署模式

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

  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/ingress/00-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/daemonset-features/01-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/smoke-statefulset/00-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/smoke-sidecar/00-install.yaml

边车注入

通过将 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 则不会。

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

为初始化容器注入 Instrumentation

可通过在 container-names 注解中包含初始化容器的名称来为其注入 instrumentation。当目标为初始化容器注入 instrumentation 时，Operator 会在 Pod 的初始化容器序列中，自动将 instrumentation 初始化容器插入到目标初始化容器之前。这确保了目标初始化容器运行时，instrumentation 代理文件已可用。

初始化容器支持的 instrumentation：

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

初始化容器不支持的 instrumentation：

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

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

同时为初始化容器和常规容器注入 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（初始化容器）和 myapp（常规容器）都将使用 Python 自动 instrumentation 进行注入。

具有多种 instrumentation 的多容器 Pod

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

需要定义要注入哪种语言 instrumentation 的注解。启用此功能后，将使用特定于 instrumentation 语言的容器注解（这些注解也支持 Java、Python、Node.js、.NET 和 SDK 的初始化容器名称）：

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

目标分配器（Target Allocator）

OpenTelemetry Operator 附带一个可选组件 Target Allocator（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

[!NOTE] 上述示例中替换键中 `# Kubernetes 的 OpenTelemetry Operator

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）实例，例如：

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

Operator 会检查配置文件以实现以下几个目的：

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

部署模式

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

  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/ingress/00-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/daemonset-features/01-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/smoke-statefulset/00-install.yaml
  • https://github.com/open-telemetry/opentelemetry-operator/blob/main/tests/e2e/smoke-sidecar/00-install.yaml

边车注入

通过将 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 则不会。

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

为初始化容器注入 Instrumentation

可通过在 container-names 注解中包含初始化容器的名称来为其注入 instrumentation。当目标为初始化容器注入 instrumentation 时，Operator 会在 Pod 的初始化容器序列中，自动将 instrumentation 初始化容器插入到目标初始化容器之前。这确保了目标初始化容器运行时，instrumentation 代理文件已可用。

初始化容器支持的 instrumentation：

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

初始化容器不支持的 instrumentation：

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

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

同时为初始化容器和常规容器注入 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（初始化容器）和 myapp（常规容器）都将使用 Python 自动 instrumentation 进行注入。

具有多种 instrumentation 的多容器 Pod

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

需要定义要注入哪种语言 instrumentation 的注解。启用此功能后，将使用特定于 instrumentation 语言的容器注解（这些注解也支持 Java、Python、Node.js、.NET 和 SDK 的初始化容器名称）：

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

目标分配器（Target Allocator）

OpenTelemetry Operator 附带一个可选组件 Target Allocator（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

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

在后台，OpenTelemetry Operator 会在协调后将 Collector 的配置转换为以下内容：

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

[!NOTE] 在这种情况下，操作员会将替换键中的 "$$" 替换为单个 "$"。这是因为 Collector 支持环境变量替换，而 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

轩辕镜像配置手册

探索更多轩辕镜像的使用方法，找到最适合您系统的配置方式

Docker 配置

登录仓库拉取

通过 Docker 登录认证访问私有仓库

专属域名拉取

无需登录使用专属域名

K8s Containerd

Kubernetes 集群配置 Containerd

K3s

K3s 轻量级 Kubernetes 镜像加速

Dev Containers

VS Code Dev Containers 配置

Podman

Podman 容器引擎配置

Singularity/Apptainer

HPC 科学计算容器配置

其他仓库配置

ghcr、Quay、nvcr 等镜像仓库

Harbor 镜像源配置

Harbor Proxy Repository 对接专属域名

Portainer 镜像源配置

Portainer Registries 加速拉取

Nexus 镜像源配置

Nexus3 Docker Proxy 内网缓存

系统配置

Linux

在 Linux 系统配置镜像服务

Windows/Mac

在 Docker Desktop 配置镜像

MacOS OrbStack

MacOS OrbStack 容器配置

Docker Compose

Docker Compose 项目配置

NAS 设备

群晖

Synology 群晖 NAS 配置

飞牛

飞牛 fnOS 系统配置镜像

绿联

绿联 NAS 系统配置镜像

威联通

QNAP 威联通 NAS 配置

极空间

极空间 NAS 系统配置服务

网络设备

爱快路由

爱快 iKuai 路由系统配置

宝塔面板

在宝塔面板一键配置镜像

需要其他帮助？请查看我们的 常见问题Docker 镜像访问常见问题解答 或 提交工单

镜像拉取常见问题

使用与功能问题

配置了专属域名后，docker search 为什么会报错？

docker search 限制

Docker Hub 上有的镜像，为什么在轩辕镜像网站搜不到？

站内搜不到镜像

机器不能直连外网时，怎么用 docker save / load 迁镜像？

离线 save/load

docker pull 拉插件报错（plugin v1+json）怎么办？

插件要用 plugin install

WSL 里 Docker 拉镜像特别慢，怎么排查和优化？

WSL 拉取慢

轩辕镜像安全吗？如何用 digest 校验镜像没被篡改？

安全与 digest

第一次用轩辕镜像拉 Docker 镜像，要怎么登录和配置？

新手拉取配置

轩辕镜像合规吗？轩辕镜像的合规是怎么做的？

镜像合规机制

轩辕镜像支持 docker push 上传本地镜像吗？

不支持 push

错误码与失败问题

docker pull 提示 manifest unknown 怎么办？

manifest unknown

docker pull 提示 no matching manifest 怎么办？

no matching manifest（架构）

镜像已拉取完成，却提示 invalid tar header 或 failed to register layer 怎么办？

invalid tar header（解压）

Docker pull 时 HTTPS / TLS 证书验证失败怎么办？

TLS 证书失败

Docker pull 时 DNS 解析超时或连不上仓库怎么办？

DNS 超时

docker 无法连接轩辕镜像域名怎么办？

域名连通性排查

Docker 拉取出现 410 Gone 怎么办？

410 Gone 排查

出现 402 或「流量用尽」提示怎么办？

402 与流量用尽

Docker 拉取提示 UNAUTHORIZED（401）怎么办？

401 认证失败

遇到 429 Too Many Requests（请求太频繁）怎么办？

429 限流

docker login 提示 Cannot autolaunch D-Bus，还算登录成功吗？

D-Bus 凭证提示

为什么会出现「单层超过 20GB」或 413，无法加速拉取？

413 与超大单层

账号 / 计费 / 权限

轩辕镜像免费版和专业版有什么区别？

免费版与专业版区别

轩辕镜像支持哪些 Docker 镜像仓库？

支持的镜像仓库

镜像拉取失败还会不会扣流量？

失败是否计费

麒麟 V10 / 统信 UOS 提示 KYSEC 权限不够怎么办？

KYSEC 拦截脚本

如何在轩辕镜像申请开具发票？

申请开票

怎么修改轩辕镜像的网站登录和仓库登录密码？

修改登录密码

如何注销轩辕镜像账户？要注意什么？

注销账户

配置与原理类

写了 registry-mirrors，为什么还是走官方或仍然报错？

mirrors 不生效

怎么用 docker tag 去掉镜像名里的轩辕域名前缀？

去掉域名前缀

如何拉取指定 CPU 架构的镜像（如 ARM64、AMD64）？

指定架构拉取

用轩辕镜像拉镜像时快时慢，常见原因有哪些？

拉取速度原因

为什么拉取镜像的 :latest 标签，拿到的往往不是「最新」镜像？

latest 与「最新」

查看全部问题→

用户好评

来自真实用户的反馈，见证轩辕镜像的优质服务

用户头像

oldzhang

运维工程师

Linux服务器

5

"Docker访问体验非常流畅，大镜像也能快速完成下载。"

轩辕镜像
镜像详情
...
ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd
博客Docker 镜像公告与技术博客
热门查看热门 Docker 镜像推荐
安装一键安装 Docker 并配置镜像源
镜像拉取问题咨询请 提交工单。官方公众号：源码跳动。官方技术交流群：51517718。轩辕镜像所有镜像均来源于原始仓库，本站不存储、不修改、不传播任何镜像内容。
镜像拉取问题咨询请提交工单。官方公众号：源码跳动。官方技术交流群：。轩辕镜像所有镜像均来源于原始仓库，本站不存储、不修改、不传播任何镜像内容。
商务合作：点击复制邮箱
©2024-2026 源码跳动
商务合作：点击复制邮箱Copyright © 2024-2026 杭州源码跳动科技有限公司. All rights reserved.