从0到1搭建Jaeger：流水线配置 | DevOps天花板

▌ 技术引导
从0到1搭建Jaeger的流水线配置，关键在于理解其核心组件与部署方式。我见过不少团队在搭建过程中把配置文件写成灾难，比如logrus格式错误、agent转发配置没对齐、zipkin的storage backend配置了错误的类型。直接上配置，不需要画蛇添足。Jaeger的docker-compose方式虽然好用，但不够灵活，尤其在多环境部署中容易出乱子。我的经验是用kustomize结合helm，把jaeger的各个组件拆分成独立的yaml，这样在不同集群中一键替换参数，效率高、风险低。另外，gRPC和Thrift的传输协议选型也要注意，gRPC更现代，但某些老系统只支持Thrift。监控策略同样重要，比如对agent的CPU和内存做限流，避免打满。用Prometheus + Grafana组合，监控trace数量、存储负载、网络延迟这些指标，能提前发现性能瓶颈。我的一个项目因为没配置好HTTP端口，导致前端无法访问，结果发现在k8s的service暴露上疏漏了nodePort。这些细节必须踩过坑才知道。

▌ 技术参考
一 技术背景与核心概念
Jaeger是分布式追踪系统，支持gRPC、Thrift、HTTP三种协议，可集成到微服务架构中。核心组件包括Collector、Agent、Storage、Query、UI。Collector负责接收trace数据，Agent负责采集和转发，Storage存储数据，Query提供查询接口，UI展示追踪结果。在DevOps环境中，Jaeger常用于监控链路调用，定位问题根源。搭建过程中需要考虑环境变量、存储类型、网络策略等，确保不同组件能正确通信。常见配置包括使用本地内存存储还是远程数据库，如Cassandra、Elasticsearch等。

二 具体操作方法或配置步骤
使用kustomize构建Jaeger的部署模板，将各个组件分开定义。例如，jaeger-agent的配置文件需指定jaeger-collector的地址，如`--collector.endpoint=jaeger-collector:14268`。Collector的配置需指定storage的类型和端口，如`--storage.type=redis`。Storage模块需要连接数据库，其中redis存储需要配置`--redis.max-connections=1000`，并挂载配置文件。Query模块需设置`--storage.type=redis`与Collector的通信参数。UI部分通常需要独立部署，配置`--query-redis-endpoint=redis:6379`。整个流程使用helm-chart打包，通过kustomize的目录结构管理不同环境的配置，比如本地测试环境和生产环境。

三 常见踩坑场景与避坑方案
配置错误是搭建Jaeger最常见的问题，比如logrus的格式写错，导致agent无法启动。使用`jaegerctl check`可快速发现问题。另一个坑是网络策略，如果jaeger-agent和collector跑在不同namespace，需要配置networkPolicy或者使用ingress允许通信。生产环境中，agent常被误配置为直连storage，导致性能下降。正确方式应是通过collector转发。另外，使用Prometheus监控时，必须配置正确的标签，比如`--prometheus.endpoint=0.0.0.0:14271`，否则无法抓取指标。还有人误把jaeger-ui的端口暴露到公网，导致安全漏洞，需通过ingress或nodePort谨慎控制访问权限。

四 性能影响或效率对比
Jaeger在高吞吐场景下对CPU和内存要求较高，尤其是collection和storage模块。使用gRPC协议相比HTTP有更小的传输开销，但需要确保依赖项已正确安装，比如protoc编译器。Thrift协议同样高效，但对某些系统兼容性差，需要测试。在存储方面，Redis比Cassandra更轻量，适合测试环境，但Cassandra在大规模数据下有更强的扩展性。Query模块的性能与存储数据量密切相关，数据量越大，查询延迟越高。如果使用Elasticsearch作为存储，需评估其节点数量和分片策略。此外，agent的配置参数如`--sampling-rate=1.0`会影响数据采集量，过高会导致存储压力，过低则丢失关键信息。

五 适用场景与局限性
Jaeger适用于微服务架构、容器化部署和混合云环境，尤其是需要细粒度追踪链路的场景。它对gRPC和Thrift协议的支持使其成为很多后端系统的首选。但在某些老系统中，可能会遇到兼容性问题，因为Jaeger默认不支持传统HTTP调用。此外，Jaeger在大规模部署时需要合理规划存储和查询模块，否则容易出现性能瓶颈。如果团队缺乏运维经验，可能难以维护jaeger的健康状态，比如监控指标和自动扩容。对于小规模项目，可以直接用docker-compose部署，但随着规模扩大，必须引入k8s和 helm 来实现自动化运维。

六 替代方案或进阶技巧
如果Jaeger无法满足需求，可以考虑使用Zipkin或OpenTelemetry。Zipkin在某些场景下更轻量，但Jaeger的存储和查询功能更强大。OpenTelemetry则支持更多协议和扩展，比如OTLP。对于Jaeger的部署，可以结合Kubernetes Operator实现自动管理，避免手动操作。另外，使用Jaeger的chained模式可以减少网络开销，但需要调整配置文件。在日志收集方面，不要只依赖jaeger-agent，应结合Fluentd或Logstash做日志归一化处理。对于跨集群的追踪需求，Jaeger的cross-cluster功能需要配置`--local-address`和`--remote-address`，确保数据能正确聚合。

七 部署配置示例
部署Jaeger时，建议使用Kubernetes helm chart，通过values.yaml配置各个组件。例如，jaeger-collector的配置包括：
```yaml
jaegerCollector:
image: jaegertracing/jaeger-collector:1.73
env:
- name: COLLECTOR_LOG_LEVEL
value: "debug"
ports:
- containerPort: 14268
resources:
limits:
memory: "2Gi"
cpu: "1"
```
jaeger-agent的配置需要注意`--sampling-rate`和`--otel-collector.endpoint`，避免因配置错误导致数据丢失。storage模块的配置需要根据实际使用的数据库类型进行调整，比如使用Redis时需设置`--storage.redis.address=redis:6379`。

八 网络策略与服务发现
Jaeger各组件依赖内部通信，必须确保服务发现和网络策略正确。在Kubernetes中，使用headless service或DNS发现，避免依赖静态IP。例如，jaeger-agent需要通过`jaeger-collector`服务名访问collector，因此必须创建Service资源并设置`clusterIP: None`。如果jaeger-ui需要被外部访问，可通过NodePort或Ingress暴露服务，比如在ingress中配置：
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: jaeger-ui
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: jaeger-ui
port:
number: 16686
```
不配置会导致UI无法访问，或者需要额外的路由规则。

九 安全配置与访问控制
Jaeger需要配置安全策略，比如使用TLS加密通信、设置RBAC规则防止未授权访问。在jaeger-query中，可以通过`--auth.jwt-secret`配置JWT认证，确保只有特定用户能访问数据。如果jaeger-agent需要采集敏感数据，应配置`--sampling.randomized`和`--sampling.priority`来控制采样策略。此外，Jaeger的metrics端口（如14271）应通过NetworkPolicy限制访问，避免被外部攻击。使用Kubernetes的NetworkPolicy可以实现细粒度的网络隔离，例如：
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: jaeger-agent-policy
spec:
podSelector:
matchLabels:
app: jaeger-agent
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 10.0.0.0/24
```
确保只有内部IP段能访问jaeger-agent。

十 日志丢弃问题与解决
Jaeger在高负载情况下可能丢弃日志，原因包括采集器队列满、存储写入失败、网络抖动等。解决方法包括调整采集器的队列大小，如在jaeger-collector中增加`--queue-size=100000`。同时，检查storage模块的写入状态，比如Redis的写入延迟或Elasticsearch的写入失败日志。监控日志丢弃率，可以通过Prometheus抓取`/metrics`接口，查看`jaeger_collector_discarded_traces_total`指标。如果丢弃率过高，需考虑扩容或调整采样率，如将`--sampling-rate=0.5`设置为0.1，减少数据量。

十一 数据采样策略与性能平衡
Jaeger支持基于优先级和随机的采样策略，优先级采样适用于关键服务，随机采样则适合大规模系统。配置`--sampling.priority=0.8`可确保关键服务的trace不被丢弃，而`--sampling.randomized=0.5`能减少存储压力。采样策略应结合业务需求动态调整，比如在测试阶段使用全采样，上线后降低比例。此外，jaeger-agent的采样策略配置必须与Collector一致，否则会引发数据不一致问题。在生产环境中，建议使用混合策略，如`--sampling.strategy=parentbased_traceid`，既能保证关键链路数据，又不会导致资源浪费。

十二 集群部署与多实例管理
Jaeger集群部署需要考虑多个collector实例的负载均衡。使用Kubernetes的Deployment管理collector，设置副本数为3，并配置Service为ClusterIP类型。同时，jaeger-query应使用headless service，让多个实例能独立运行并对外暴露。在多实例环境下，jaeger-ui必须配置正确的查询地址，如`--query-redis-endpoint=redis:6379`，避免连接错误。此外，jaeger-storage需要确保数据持久化，比如使用Cassandra的持久化卷，避免数据丢失。如果使用Redis作为存储，需配置集群模式并设置`--redis.sentinel.master-name=master`，提高可用性。

十三 资源限制与自动扩展
Jaeger组件必须设置资源限制，否则容易出现OOM或CPU过载。使用Kubernetes的ResourceRequest和ResourceLimit，例如：
```yaml
resources:
limits:
memory: "4Gi"
cpu: "2"
requests:
memory: "2Gi"
cpu: "1"
```
Collector和Query模块通常需要较高的内存，而Agent则可以较低。自动扩展可结合HPA实现，但需监控CPU和内存使用率，比如设置`minReplicas=2`，`maxReplicas=5`。在某些场景下，可以将jaeger-query部署为StatefulSet，确保实例稳定性。此外，监控jaeger的metrics如`jaeger_storage_bytes_used`和`jaeger_query_latency`，能帮助判断资源是否充足。

十四 配置备份与恢复策略
Jaeger的配置文件和存储数据必须定期备份。对于jaeger-agent，可以通过ConfigMap保存配置，并设置`--backup-path=/backup`。对于jaeger-storage，如使用Cassandra，需配置定期快照，同时设置`--storage.cassandra.backup-interval=86400`。Jaeger的UI配置同样应备份，避免误操作导致恢复困难。如果存储数据丢失，需通过`jaegerctl`工具恢复，并检查一致性哈希配置是否正确。此外，jaeger的trace数据最好存储在持久化卷中，避免因节点重启导致数据丢失。

十五 集成OTLP与自定义协议
Jaeger支持OTLP协议，可通过`--otlp.endpoint=0.0.0.0:4317`暴露端口。在使用OpenTelemetry Collector时，需配置OTLP导出器，如`otlp: { endpoint: "jaeger-collector:14268", headers: { "traceparent": "..." } }`。此外，Jaeger可通过Thrift协议与APM工具集成，比如在jaeger-agent中设置`--thrift.endpoint=jaeger-thrift:6831`。如果需要自定义协议，可以开发gRPC服务并对接Jaeger的Collector，确保数据格式兼容。同时，注意协议版本差异，如Thrift v1和v2的兼容性问题，避免对接失败。