探索服务网格与 OpenTelemetry 的协同之分布式跟踪
2023/12/14 21:02:55
本文主要是介绍探索服务网格与 OpenTelemetry 的协同之分布式跟踪,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
在上一篇文章中,介绍了 如何在 k8s 中无侵入安装 Otel 探针 并实现了无侵入(某些语言还无法实现,比如 Go 的 eBPF 对内核的苛刻要求)的分布式跟踪。
这篇文章发出后有读者评论 javaagent 的“无侵入”一说,这里有必要解释下。“无侵入”主要指的是不需要修改应用程序的业务逻辑代码就能实现的功能,对应用程序透明无感知,让开发者专注于业务开发;同时由于无需修改应用程序代码,更易于集成;同时还维护简单,在多种语言、框架间保证功能的一致性。
而 Java Agent 在 JVM 启动时加载,它在运行时修改字节码来注入跟踪代码,而不是在应用程序的源代码层面上进行修改。
背景
分布式跟踪
分布式跟踪是监控和诊断微服务请求流程的关键技术,也是可观测性的关键组成部分,提供了对微服务架构中复杂交互和性能问题的深入洞察。它通过提供服务间请求链路的清晰视图来管理复杂性,并帮助识别性能瓶颈、优化资源分配、快速定位和解决故障,提高系统的整体可靠性。
服务网格的无侵入式分布式跟踪
又是无侵入性!服务网格中的代理自动处理所有入站和出站的网络通信,自动捕获、记录和分析服务间的请求和响应的详细信息,如请求时间、持续时间、状态代码和其他元数据。这种 实现方式 对应用程序本身透明,并且较 Java Agent 在运行时修改字节码更加彻底。
这里有个前提是应用程序能够在请求中传递上下文信息,这样 sidecar 代理生成和发送的跟踪信息最终可以串联在一起,不会发生断链。
网格的无侵入式分布式跟踪虽然为我们展示了请求的链路,但是如上图所示每个跨度(span)都是 sidecar 代理的信息。
紧跟上篇文章之后,我们今天将探索 服务网格 FSM 与 OpenTelemetry 的集成,实现应用、网格的全链路分布式跟踪。
演示
架构
环境配置
Jaeger、cert-manager 和 Otel operator 的安装,请参考 上一篇文章。
配置 Instrumentation
接下来就是配置探针的安装和配置了,详细的配置说明,可以参考 Instrumentation API 文档。
根据 FSM 分布式跟踪文档 的介绍,FSM 支持 Zipkin 的协议,因此在 propagators
中我们使用 b3multi
,使用 B3 的多标头格式,在请求头中传递如下的信息:
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
这次使用 sample
命名空间。
kubectl create namespace sample kubectl apply -n sample -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: instrumentation-sample spec: propagators: - b3multi sampler: type: parentbased_traceidratio argument: "1" env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: otel-collector.default:4318 EOF
配置 OpenTelemetry Collector
Otel 收集器的详细配置可以参考 官方文档。
- 接收器(receiver),我们配置
otlp
来接收来自应用程序的跟踪信息,使用zipkin
来接收来自 sidecar 的上报,使用端点0.0.0.0:9411
。 - 输出器(exporter),配置 Jager 的 otlp 端点
jaeger.default:4317
。 - 管道服务(pipeline service),使用
otlp
和zipkin
作为输入源,将 jaeger 作为输出目的地。
kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: otel spec: config: | receivers: otlp: protocols: grpc: http: zipkin: endpoint: "0.0.0.0:9411" exporters: otlp/jaeger: endpoint: "jaeger.default:4317" tls: insecure: true service: pipelines: traces: receivers: [otlp, zipkin] exporters: [otlp/jaeger] EOF
安装服务网格 FSM
我们通过 CLI 来安装 FSM,现下载 FSM 使用当前最新的正式版 1.1.4。
system=$(uname -s | tr '[:upper:]' '[:lower:]') arch=$(uname -m | sed -E 's/x86_/amd/' | sed -E 's/aarch/arm/') release=v1.1.4 curl -L https://github.com/flomesh-io/fsm/releases/download/$release/fsm-$release-$system-$arch.tar.gz | tar -vxzf - ./$system-$arch/fsm version
在安装时,启用分布式跟踪并将地址指向 Otel Collector 的 zipkin 接收器,zipkin 接收器端点为 /api/v2/spans
。
fsm install \ --set=fsm.tracing.enable=true \ --set=fsm.tracing.address=otel-collector.default \ --set=fsm.tracing.port=9411 \ --set=fsm.tracing.endpoint=/api/v2/spans
部署示例应用
将命名空间 sample
加入到服务网格中,部署应用。
fsm namespace add sample kubectl apply -n sample -f https://raw.githubusercontent.com/addozhang/http-sample/main/manifests/service-v1.yaml
确认应用 pod 注入 sidecar 并正常运行。
kubectl get po -n sample NAME READY STATUS RESTARTS AGE service-c-66bf9dcc7b-pdj8p 2/2 Running 0 38s service-b-586cfc5ccd-k9qrs 2/2 Running 0 37s service-a-7cf7bc5bcc-tgjzz 2/2 Running 0 37s
测试
pod_name="$(kubectl get pod -n sample -l app=service-a -o jsonpath='{.items[0].metadata.name}')" kubectl port-forward -n sample $pod_name 8080:8080 & curl localhost:8080
发送请求后,打开 Jaeger UI。
jaeger_pod="$(kubectl get pod -l app=jaeger -o jsonpath='{.items[0].metadata.name}')" kubectl port-forward $jaeger_pod 16686:16686 &
在 Jaeger UI 中,可以看到链路的内容更加的丰富:包含了应用程序和 sidecar 代理的跨度数据。
这篇关于探索服务网格与 OpenTelemetry 的协同之分布式跟踪的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-12-23Fluss 写入数据湖实战
- 2024-12-22揭秘 Fluss:下一代流存储,带你走在实时分析的前沿(一)
- 2024-12-20DevOps与平台工程的区别和联系
- 2024-12-20从信息孤岛到数字孪生:一本面向企业的数字化转型实用指南
- 2024-12-20手把手教你轻松部署网站
- 2024-12-20服务器购买课程:新手入门全攻略
- 2024-12-20动态路由表学习:新手必读指南
- 2024-12-20服务器购买学习:新手指南与实操教程
- 2024-12-20动态路由表教程:新手入门指南
- 2024-12-20服务器购买教程:新手必读指南