回复
OpenTelemetry入门看这一篇就够了
WilliamGates
发布于 2023-11-23 14:21
浏览
0收藏
OpenTelemetry Collector 部署模式/策略
OpenTelemetry 收集器可以通过不同的方式进行部署，所以我们要考虑下如何部署它。具体选择哪种策略取决于你的团队和组织情况。
Agent 模式
在这种情况下，OpenTelemetry 检测的应用程序将数据发送到与应用程序一起驻留的（收集器）代理。然后，该代理程序将接管并处理所有来自应用程序的追踪数据。
收集器可以通过 sidecar 方式部署为代理，sidecar 可以配置为直接将数据发送到存储后端。
Gateway 模式
还可以决定将数据发送到另一个 OpenTelemetry 收集器，然后从（中心）收集器进一步将数据发送到存储后端。在这种配置中，我们有一个中心的 OpenTelemetry 收集器，它使用 deployment 模式部署，具有许多优势，如自动扩展。
使用中心收集器的一些优点是：
- 消除对团队的依赖
- 强制执行批处理、重试、加密、压缩的配置/策略
- 在中心位置进行身份验证
- 丰富的元数据信息
- 进行抽样决策
- 通过 HPA 进行扩展
部署模式总结
下面我们总结下常见的一些部署策略。
基本版 - 客户端使用 OTLP 进行检测，将数据发送到一组收集器。
可以将数据发送到多个导出器。
在 Kubernetes 上部署 OpenTelemetry Collector 时可以使用的模式
sidecar 模式：
代理作为 sidecar，其中使用 OpenTelemetry Collector 将容器添加到工作负载 Pod。然后，该实例被配置为将数据发送到可能位于不同命名空间或集群中的外部收集器。
daemonset 模式：
Agent 作为 DaemonSet，这样我们每个 Kubernetes 节点就有一个代理 pod。
负载均衡 - 基于 trace id 的负载均衡：
多集群 - 代理、工作负载和控制平面收集器：
多租户模式
两个租户，每个租户都有自己的 Jaeger。
信号模式
两个收集器，每个收集器对应一种遥测数据类型。
OpenTelemetry 后端
OpenTelemetry 收集器并不提供自己的后端，所以可以使用任何供应商或开源产品！
尽管 OpenTelemetry 不提供自己的后端，但通过使用它，我们不会依赖于任何工具或供应商，因为它与供应商无关。我们不仅可以使用我们想要的任何编程语言，而且还可以选择存储后端，并且只需配置另一个导出器即可轻松切换到另一个后端/供应商。
为了可视化和分析遥测数据，我们只需要在 OpenTelemetry 采集器种配置一个导出器。
比如 Jaeger 就是一个非常流行的用于分析和查询数据的开源产品。
我们可以在 OpenTelemetry 收集器中配置 Jaeger 导出器，以便将数据发送到 Jaeger。
exporters:
jaeger:
endpoint: "http://localhost:14250"OpenTelemetry on Kubernetes
在 Kubernetes 上使用 OpenTelemetry，主要就是部署 OpenTelemetry 收集器。我们建议使用 OpenTelemetry Operator 来部署，因为它可以帮助我们轻松部署和管理 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 证书。
为了简单我们这里直接使用自动生成签名证书的方式，使用下面的命令一键安装 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正常部署完成后可以看到对应的 Pod 已经正常运行：
$ kubectl get pods -n kube-otel -l app.kubernetes.io/name=opentelemetry-operator
NAME READY STATUS RESTARTS AGE
opentelemetry-operator-6f77dc895c-4wn8z 2/2 Running 0 33s此外还会自动为我们添加两个 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 收集器，并让其他 OpenTelemetry 代理将数据发送到该收集器。从代理接收的数据将在此收集器上进行处理，并通过导出器发送到存储后端。整个工作流如下图所示：
创建一个如下所示的 OpenTelemetryCollector 实例对象：
# central-collector.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: simplest
spec:
config: |
receivers:
otlp:
protocols:
grpc:
http:
processors:
memory_limiter:
check_interval: 1s
limit_percentage: 75
spike_limit_percentage: 15
batch:
send_batch_size: 10000
timeout: 10s
exporters:
logging:
otlp:
endpoint: "<tempo_endpoint>"
headers:
authorization: Basic <api_token> # echo -n "<your user id>:<your api key>" | base64
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [logging, otlp]在这里 OpenTelemetry Collector 通过 grpc 和 http 两种协议来接收遥测数据，并通过日志记录导出和 Grafana Tempo 来记录这些 Span，这会将 Span 写入接收 Span 的 OpenTelemetry Collector 实例的控制台和 Grafana Tempo 后端去。
然后我们将使用 Sidecar 模式部署 OpenTelemetry 代理。该代理会将应用程序的追踪发送到我们的中心（网关）OpenTelemetry 收集器。
# sidecar.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: sidecar
spec:
mode: sidecar
config: |
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
exporters:
logging:
otlp:
endpoint: "<path_to_central_collector>.<namespace>:4317"
service:
telemetry:
logs:
level: "debug"
pipelines:
traces:
receivers: [otlp]
processors: []
exporters: [logging, otlp]自动检测
OpenTelemetry Operator 可以注入和配置 OpenTelemetry 自动检测库。目前支持 DotNet、Java、NodeJS、Python 和 Golang（需要手动开启）。
要使用自动检测，需要为 SDK 和检测配置添加一个 Instrumentation 资源。比如对于 Java 应用程序，配置如下。
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: java-instrumentation
spec:
propagators:
- tracecontext
- baggage
- b3
sampler:
type: always_on
java:如果是 Python 应用程序，配置如下：
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: python-instrumentation
spec:
propagators:
- tracecontext
- baggage
- b3
sampler:
type: always_on
python:要启用检测，我们需要更新部署文件并向其添加注解。通过这种方式，我们告诉 OpenTelemetry Operator 将 sidecar 和 java 工具注入到我们的应用程序中。
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
sidecar.opentelemetry.io/inject: "true"示例应用
这里我们将使用一个名为 Petclinic 的 Java 应用程序，这是一个使用 Maven 或 Gradle 构建的 Spring Boot 应用程序。该应用程序将使用 OpenTelemetry 生成数据。
对于 Java 应用，我们可以通过下载 OpenTelemetry 提供的 opentelemetry-javaagent 这个 jar 包来使用 OpenTelemetry 自动检测应用程序。
只需要将这个 jar 包添加到应用程序的启动命令中即可，比如：
java -javaagent:opentelemetry-javaagent.jar -jar target/*.jarJava 自动检测使用可附加到任何 Java 8+ 应用程序的 Java 代理 JAR。它动态注入字节码以从许多流行的库和框架捕获遥测数据。它可用于捕获应用程序或服务“边缘”的遥测数据，例如入站请求、出站 HTTP 调用、数据库调用等。通过运行以上命令，我们可以对应用程序进行插桩，并生成链路数据，而对我们的应用程序没有任何修改。
尤其是在 Kubernetes 环境中，我们可以使用 OpenTelemetry Operator 来注入和配置 OpenTelemetry 自动检测库，这样连 javaagent 我们都不需要去手动注入了。
我们首先部署 Petclinic 应用程序。
apiVersion: apps/v1
kind: Deployment
metadata:
name: petclinic
spec:
selector:
matchLabels:
app: petclinic
template:
metadata:
labels:
app: petclinic
spec:
containers:
- name: app
image: cnych/spring-petclinic:latest然后我们为 Java 应用程序添加一个 Instrumentation 资源。
# java-instrumentation.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: java-instrumentation
spec:
propagators:
- tracecontext
- baggage
- b3
sampler:
type: always_on
java:
image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest为了启用自动检测，我们需要更新部署文件并向其添加注解。这样我们可以告诉 OpenTelemetry Operator 将 sidecar 和 java-instrumentation 注入到我们的应用程序中。修改 Deployment 配置如下：
# petclinic.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: petclinic
spec:
selector:
matchLabels:
app: petclinic
template:
metadata:
labels:
app: petclinic
annotations:
instrumentation.opentelemetry.io/inject-java: "true"
sidecar.opentelemetry.io/inject: "sidecar"
spec:
containers:
- name: app
image: cnych/spring-petclinic:latest然后再创建一个 NodePort 类型的 Service 服务来暴露应用程序。
# petclinic-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: petclinic
spec:
selector:
app: petclinic
type: NodePort
ports:
- protocol: TCP
port: 80
targetPort: 8080直接应用上面的资源清单即可：
$ kubectl apply -f central-collector.yaml
$ kubectl apply -f sidecar.yaml
$ kubectl apply -f java-instrumentation.yaml
$ kubectl apply -f petclinic.yaml
$ kubectl apply -f petclinic-svc.yaml正常部署完成后可以看到对应的 Pod 已经正常运行：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
petclinic-6fdd56f4d7-qfff7 2/2 Running 0 62s
simplest-collector-87d8bf9bf-dh8pl 1/1 Running 0 36m
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
petclinic NodePort 10.103.6.52 <none> 80:30941/TCP 46s
simplest-collector ClusterIP 10.102.131.126 <none> 4317/TCP,4318/TCP 17m
simplest-collector-headless ClusterIP None <none> 4317/TCP,4318/TCP 17m
simplest-collector-monitoring ClusterIP 10.98.65.171 <none> 8888/TCP 17m然后我们就可以通过 http://<node_ip>:30941 来访问 Petclinic 应用程序了。
当我们访问应用程序时，应用程序就将生成追踪数据，并将其发送到我们的中心收集器。我们可以通过访问 Grafana Tempo 来查看追踪数据，同时也可以通过访问中心收集器的控制台来查看追踪数据。因为我们在中心收集器中配置了日志记录导出器和 Grafana Tempo 两个导出器，当然也可以配置其他导出器。
$ kubectl logs -f petclinic-6fdd56f4d7-qfff7 -c otc-container
# ......
2023-09-10T04:11:41.164Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76}
2023-09-10T04:12:11.012Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 3}
2023-09-10T04:12:16.221Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 23}
^C
$ kubectl logs -f simplest-collector-677f4779ff-x8h2m
# ......
2023-09-10T04:11:09.221Z info service/service.go:161 Everything is ready. Begin running and processing data.
2023-09-10T04:11:49.222Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76}
2023-09-10T04:12:19.224Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 2, "spans": 26}所以在 Grafana Tempo 中也可以看到对应的追踪数据：
同样如果你再添加一个 Jaeger 的导出器，那么你也可以在 Jaeger 中看到对应的追踪数据。
如果在部署中遇到任何问题，我们可以通过查看应用程序和容器的日志来进行排查。
总结
在这篇文章中，我们演示了如何使用 OpenTelemetry Operator 在应用程序中实现追踪，而无需更改任何代码。
当然其中还有很多其他内容没有涉及到，比如如何在 OpenTelemetry 中使用 Prometheus 来收集指标数据，如何在 OpenTelemetry 中使用 Loki 来收集日志数据等等，也包括一些采样策略、传播器、批处理器、手动检测等等。
参考文档
- https://medium.com/@magstherdev/opentelemetry-up-and-running-b4c58eaf8c05
- https://medium.com/@magstherdev/opentelemetry-on-kubernetes-c167f024b35f
- https://medium.com/@magstherdev/opentelemetry-in-action-fc61263c852
- https://github.com/open-telemetry/opentelemetry-go-instrumentation
文章转载自公众号：k8s技术圈
分类
已于2023-11-23 14:21:20修改
赞
收藏
回复
相关推荐
