使用OpenTelemetry Operator将可观测数据发送到SigNoz

WilliamGates

发布于 2023-11-23 14:02

浏览

0收藏

OpenTelemetry Operator 是一个用于部署和管理 OpenTelemetry 组件的 Kubernetes Operator。它是一个自定义的 Kubernetes 控制器，使用 Operator 模式自动化了 OpenTelemetry 环境的部署、配置和管理过程。

OpenTelemetry Operator 简化了在 Kubernetes 环境中部署和管理 OpenTelemetry Collector、OpenTelemetry Agent 等组件的流程。它可以通过 CRD 对 OpenTelemetry 组件进行集中化的管理。使用 OpenTelemetry Operator，可以轻松地在 Kubernetes 集群中创建、配置和管理 OpenTelemetry 组件的实例。它提供了许多有用的功能，例如自动创建和管理配置文件、自动注入收集器和代理配置、自动监视和扩展等。

部署

这里我们使用 Helm Chart 来部署 OpenTelemetry Operator，首先添加 Helm Chart 仓库：

$ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
$ helm repo update

默认情况下会部署一个准入控制器，用于验证 OpenTelemetry Operator 的配置是否正确，为了使 APIServer 能够与 Webhook 组件进行通信，Webhook 需要一个由 APIServer 配置为可信任的 TLS 证书。有几种不同的方法可以用来生成/配置所需的 TLS 证书。

最简单的（默认）方法是安装 cert-manager 并将admissionWebhooks.certManager.create 设置为 true。这样，cert-manager 就会生成一个自签名的证书。
可以通过配置admissionWebhooks.certManager.issuerRef 值来提供自己的颁发者。需要指定类型（Issuer 或 ClusterIssuer）和名称。请注意，此方法还是需要安装 cert-manager。
可以通过将admissionWebhooks.certManager.enabled 设置为 false 并将admissionWebhooks.autoGenerateCert 设置为 true 来使用自动生成的自签名证书。Helm 将创建一个自签名证书和一个对应的 Secret。
可以通过将admissionWebhooks.certManager.enabled 和admissionWebhooks.autoGenerateCert 设置为 false 来使用自己生成的自签名证书。需要向admissionWebhooks.cert_file、admissionWebhooks.key_file 和admissionWebhooks.ca_file 提供必要的值。
可以通过禁用.Values.admissionWebhooks.create 和admissionWebhooks.certManager.enabled 来通过路径挂载自定义 Webhooks 和证书，同时在admissionWebhooks.secretName 中设置自定义证书 Secret 名称。
可以通过禁用.Values.admissionWebhooks.create 并将 env var 设置为ENABLE_WEBHOOKS: "false" 来完全禁用 Webhooks。

为了简单我们这里可以选择第三种方式，直接使用自动生成的自签名证书，直接使用下面的命令一键安装 OpenTelemetry Operator：

$ helm upgrade --install --set admissionWebhooks.certManager.enabled=false --set admissionWebhooks.certManager.autoGenerateCert=true opentelemetry-operator open-telemetry/opentelemetry-operator --namespace kube-otel --create-namespace

Release "opentelemetry-operator" does not exist. Installing it now.
NAME: opentelemetry-operator
LAST DEPLOYED: Tue Sep  5 11:23:29 2023
NAMESPACE: kube-otel
STATUS: deployed
REVISION: 1
NOTES:
opentelemetry-operator has been installed. Check its status by running:
  kubectl --namespace kube-otel get pods -l "release=opentelemetry-operator"

Visit https://github.com/open-telemetry/opentelemetry-operator for instructions on how to create & configure OpenTelemetryCollector and Instrumentation custom resources by using the Operator.

正常部署完成后可以看到对应的 Pod 已经正常运行：

$ kubectl get pods -n kube-otel -l app.kubernetes.io/name=opentelemetry-operator
NAME                                      READY   STATUS    RESTARTS   AGE
opentelemetry-operator-6f77dc895c-924gf   2/2     Running   0          3m30s

此外还会自动为我们添加两个 OpenTelemetry 相关的 CRD：

$ kubectl get crd |grep opentelemetry
instrumentations.opentelemetry.io           2023-09-05T03:23:28Z
opentelemetrycollectors.opentelemetry.io    2023-09-05T03:23:28Z

到这里 OpenTelemetry Operator 就部署完成了。

配置

OpenTelemetry Operator 可以通过 CRD 来管理 OpenTelemetry 组件，其有 3 种不同的部署模式可用：

DaemonSet
Sidecar
Deployment（默认模式）

OpenTelemetryCollector 类型的 CustomResource 暴露一个名为 .Spec.Mode 的属性，该属性可用于指定收集器是否应作为 DaemonSet、Sidecar 或 Deployment（默认）运行。

Deployment 模式

我们可以订阅一个如下所示的 OpenTelemetryCollector CRD，用来部署一个 Deployment 模式的 OpenTelemetry Collector：

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: simplest
spec:
  mode: deployment
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
    exporters:
      logging:
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [logging]EOF

上面的 otelcol 示例使用 gRPC 和 HTTP 协议接收 OTLP 跟踪数据，对数据进行批处理并将其记录到控制台。应用该资源对象后，OpenTelemetry Operator 将创建一个名为 simplest 的 Deployment，该 Deployment 将运行一个 OpenTelemetry Collector 实例，该实例将使用上面的配置来接收、处理和导出跟踪数据。

$ kubectl get opentelemetrycollectors
NAME       MODE         VERSION   READY   AGE     IMAGE                                         MANAGEMENT
simplest   deployment   0.83.0    1/1     3m22s   otel/opentelemetry-collector-contrib:0.83.0   managed
$ kubectl get pods
NAME                                     READY   STATUS    RESTARTS       AGE
simplest-collector-6d9886f5d-shgdb       1/1     Running   0              3m30s
$ kubectl get svc
NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                        AGE
kubernetes                      ClusterIP   10.96.0.1        <none>        443/TCP                        179d
simplest-collector              ClusterIP   10.108.169.24    <none>        4317/TCP,4318/TCP              3m43s
simplest-collector-headless     ClusterIP   None             <none>        4317/TCP,4318/TCP              3m43s
simplest-collector-monitoring   ClusterIP   10.103.173.212   <none>        8888/TCP                       3m43s

接下来我们可以按照以下步骤来安装一个 telemetrygen 工具，然后将示例跟踪发送到这个收集器进行测试：

$ go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest

然后转发 OTLP 服务的 gRPC 端口：

$ kubectl port-forward service/simplest-collector 4317

在另一个终端中，执行以下命令以使用 telemetrygen 发送跟踪数据：

$ telemetrygen traces --traces 1 --otlp-endpoint localhost:4317 --otlp-insecure

然后我们可以查看采集器对应的日志，正常可以看到如下所示的日志：

$ kubectl logs -l app.kubernetes.io/name=simplest-collector
2023-09-05T06:18:43.299Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 2}

最后，请确保清理 otelcol 实例。

$ kubectl delete otelcol simplest

DaemonSet 模式

同样，OpenTelemetry Collector 实例可以使用 DaemonSet 模式部署，这确保所有（或部分）节点运行收集器 pod 的副本。对于 DaemonSet，只有 Spec.Mode 属性会更新为 daemonset。而前面的 otelcol YAML 示例中的配置可以保持原样，也可以根据需要进行更新。

DaemonSet 适用于诸如日志收集守护程序、存储守护程序和节点监控守护程序等任务。在这些情况下，需要在每个节点上运行一个收集器实例，以便从每个节点收集数据，前面其实我们已经介绍过。

Sidecar 模式

通过将 pod 注解 sidecar.opentelemetry.io/inject 设置为 true 或来自同一命名空间的具体 OpenTelemetryCollector 的名称，可以将具有 OpenTelemetry Collector 的 sidecar 注入到基于 pod 的工作负载中。

如下所示是创建一个以 jaeger 作为输入并将输出记录到控制台的 Sidecar 的示例：

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: my-sidecar
spec:
  mode: sidecar
  config: |
    receivers:
      jaeger:
        protocols:
          thrift_compact:
    processors:
    exporters:
      logging:
    service:
      pipelines:
        traces:
          receivers: [jaeger]
          processors: []
          exporters: [logging]
EOF

该示例将创建一个名为 my-sidecar 的 OpenTelemetry Collector sidecar，该 sidecar 将从 Jaeger 接收跟踪数据并将其记录到控制台。

$ kubectl get opentelemetrycollectors
NAME         MODE      VERSION   READY   AGE   IMAGE   MANAGEMENT
my-sidecar   sidecar   0.83.0            11s           managed

接下来，我们使用一个 jaeger 示例镜像来创建一个 Pod，并将 sidecar.opentelemetry.io/inject 注解设置为 true：

$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  annotations:
    sidecar.opentelemetry.io/inject: "true"  # 注入 otelcol sidecar
spec:
  containers:
  - name: myapp
    image: jaegertracing/vertx-create-span:operator-e2e-tests
    ports:
      - containerPort: 8080
        protocol: TCP
EOF

应用该 Pod 后，OpenTelemetry Operator 会将上面定义的 my-sidecar 采集器作为 sidecar 注入到 Pod 中，该容器将运行一个 OpenTelemetry Collector 实例，该实例将使用上面的配置来接收、处理和导出跟踪数据。

$ kubectl get pods myapp
NAME    READY   STATUS    RESTARTS   AGE
myapp   2/2     Running   0          110s

使用OpenTelemetry Operator将可观测数据发送到SigNoz-鸿蒙开发者社区

这里我们可以转发下 myapp pod 的 8080 端口：

$ kubectl port-forward pod/myapp 8080:8080

然后在另一个终端中，使用 curl 发送 HTTP 请求：

$ curl http://localhost:8080
Hello from Vert.x!

然后可以查看 Sidecar 容器的输出日志，正常可以看到如下所示的 Trace 日志：

$ kubectl logs pod/myapp -c otc-container
# .......
2023-09-05T06:45:56.648Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 4}
2023-09-05T06:45:56.648Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 5}
2023-09-05T06:46:04.638Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 4}
2023-09-05T06:46:04.638Z        info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 5}

最后记得清理 Sidecar 和 myapp pod:

$ kubectl delete otelcol/my-sidecar
$ kubectl delete pod/myapp

OpenTelemetry 自动埋点注入

OpenTelemetry Operator 除了可以管理 OpenTelemetry Collector 之外，还可以注入和配置 OpenTelemetry 自动追踪库。

埋点资源配置

目前，支持 Java、NodeJS、Python 和 DotNet 语言的埋点。当以下注解应用于工作负载或命名空间时，将启用仪器化。

instrumentation.opentelemetry.io/inject-java: "true" — 对于 Java
instrumentation.opentelemetry.io/inject-nodejs: "true" — 对于 NodeJS
instrumentation.opentelemetry.io/inject-python: "true" — 对于 Python
instrumentation.opentelemetry.io/inject-dotnet: "true" — 对于 DotNet
instrumentation.opentelemetry.io/inject-sdk: "true" - 仅适用于 OpenTelemetry SDK 环境变量

注解的可能值有：

true - 从命名空间注入和埋点资源。
my-instrumentation - 当前命名空间中Instrumentation CR 实例的名称。
my-other-namespace/my-instrumentation - 另一个命名空间中Instrumentation CR 实例的名称和命名空间。
false -不注入。

在使用自动插桩之前，我们需要使用 SDK 和插桩的配置来配置一个 Instrumentation 资源。

Instrumentation 由以下属性组成：

exporter.endpoint -（可选）将遥测数据发送到 OTLP 格式的地址。
propagators - 使所有数据源能够共享底层上下文机制，用于在事务的整个生命周期中存储状态和访问数据。
sampler - 通过减少收集和发送到后端的跟踪样本数量来引入的噪音和开销的机制。 OpenTelemetry 提供两种类型：StaticSampler 和TraceIDRatioBased。
语言属性，即java、nodejs、python 和dotnet - 根据 pod 注解中设置的语言，使用自动插桩的自定义镜像。

文章转载自公众号：k8s技术圈

分类

其他

标签

SigNoz

已于2023-11-23 14:02:46修改

51CTO

51CTO博客

51CTO学堂