探索服务网格与 OpenTelemetry 的协同之分布式跟踪

这篇文章发出后有读者评论 javaagent 的“无侵入”一说,这里有必要解释下。“无侵入”主要指的是不需要修改应用程序的业务逻辑代码就能实现的功能,对应用程序透明无感知,让开发者专注于业务开发;同时由于无需修改应用程序代码,更易于集成;同时还维护简单,在多种语言、框架间保证功能的一致性。

而 Java Agent 在 JVM 启动时加载,它在运行时修改字节码来注入跟踪代码,而不是在应用程序的源代码层面上进行修改。

背景

分布式跟踪

分布式跟踪是监控和诊断微服务请求流程的关键技术,也是可观测性的关键组成部分,提供了对微服务架构中复杂交互和性能问题的深入洞察。它通过提供服务间请求链路的清晰视图来管理复杂性,并帮助识别性能瓶颈、优化资源分配、快速定位和解决故障,提高系统的整体可靠性。

服务网格的无侵入式分布式跟踪

又是无侵入性!服务网格中的代理自动处理所有入站和出站的网络通信,自动捕获、记录和分析服务间的请求和响应的详细细心,如请求时间、持续时间、状态代码和其他元数据。这种 实现方式[1] 对应用程序本身透明,并且较 Java Agent 在运行时修改字节码更加彻底。

这里有个前提是应用程序能够在请求中传递上下文信息,这样 sidecar 代理生成和发送的跟踪信息最终可以串联在一起,不会发生断链。

图片

网格的无侵入式分布式跟踪虽然为我们展示了请求的链路,但是如上图所示每个跨度(span)都是 sidecar 代理的信息。

紧跟上篇文章之后,我们今天将探索 服务网格 FSM[2] 与 OpenTelemetry 的集成,实现应用、网格的全链路分布式跟踪。

演示

架构

图片

环境配置

Jaeger、cert-manager 和 Otel operator 的安装,请参考 上一篇文章。

配置 Instrumentation

接下来就是配置探针的安装和配置了,详细的配置说明,可以参考 Instrumentation API 文档[3]。

根据 FSM 分布式跟踪文档[4] 的介绍,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 收集器的详细配置可以参考 官方文档[5]。

  • 接收器(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 jsnotallow='{.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 jsnotallow='{.items[0].metadata.name}')"
kubectl port-forward $jaeger_pod 16686:16686 &

在 Jaeger UI 中,可以看到链路的内容更加的丰富:包含了应用程序和 sidecar 代理的跨度数据。

图片

参考资料

[1] 实现方式: https://fsm-docs.flomesh.io/guides/observability/tracing/

[2] 服务网格 FSM: http://fsm-docs.flomesh.io

[3] Instrumentation API 文档: https://github.com/open-telemetry/opentelemetry-operator/blob/main/docs/api.md#instrumentation

[4] FSM 分布式跟踪文档: https://fsm-docs.flomesh.io/guides/observability/tracing/

[5] 官方文档: https://opentelemetry.io/docs/collector/configuration/

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/244692.html<

(0)
管理的头像管理
上一篇2025-04-25 20:30
下一篇 2025-04-25 20:32

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注