零依赖部署：Jaeger纯查询服务与OTEL Collector的5分钟集成方案

你是否在为Jaeger全栈部署消耗过多服务器资源而烦恼？是否需要一个轻量级方案仅保留查询分析能力？本文将带你通过OTEL Collector实现Jaeger纯查询服务架构，仅需3步即可完成配置，让分布式追踪系统部署成本降低60%。读完本文你将掌握：

• 纯查询服务的资源隔离部署架构
• OTEL Collector与Jaeger的无缝数据对接
• 基于现有项目配置文件的快速改造方案

架构解析：为什么需要纯查询服务？

传统Jaeger部署包含收集器（Collector）、查询服务（Query）、存储和Agent等组件，对于仅需数据分析的场景显得冗余。纯查询服务架构通过OTEL Collector接管数据摄入，Jaeger仅保留查询功能，实现：

graph LR
    A[应用程序] -->|OTLP协议| B[OTEL Collector]
    B -->|存储写入| C[(Elasticsearch/Cassandra)]
    D[Jaeger Query] -->|数据读取| C
    D --> E[Web UI]

这种架构的核心优势在于：

• 资源隔离：查询服务独立扩展，避免分析操作影响数据收集
• 多源数据整合：OTEL Collector可接收来自Zipkin、OpenTelemetry等多源数据
• 弹性部署：支持查询服务的蓝绿部署和版本快速迭代

项目中提供的架构示意图：

配置实战：3步实现纯查询服务

步骤1：准备环境与获取配置模板

首先克隆项目仓库并进入配置目录：

git clone https://gitcode.com/GitHub_Trending/ja/jaeger
cd jaeger/docker-compose/monitor

关键配置文件说明：

文件名	作用	相对路径
otel-collector-config-connector.yml	OTEL数据接收与转发配置	docker-compose/monitor/otel-collector-config-connector.yml
config-query.yaml	Jaeger查询服务专用配置	cmd/jaeger/config-query.yaml
docker-compose.yml	服务编排定义	docker-compose/monitor/docker-compose.yml

步骤2：配置OTEL Collector数据管道

修改OTEL Collector配置，设置数据接收端点和存储导出：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"
      http:
        endpoint: "0.0.0.0:4318"

exporters:
  elasticsearch:
    endpoints: ["http://elasticsearch:9200"]
    index: "jaeger-spans-%{+yyyy.MM.dd}"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [elasticsearch]

完整配置示例可参考项目中的otel-collector-config-connector.yml，该文件已预设Jaeger兼容的OTLP接收器配置。

步骤3：配置Jaeger纯查询模式

修改Jaeger配置文件config-query.yaml，禁用内置收集器并启用存储后端连接：

service:
  extensions: [jaeger_storage, jaeger_query, healthcheckv2]
  pipelines:
    traces:
      receivers: [nop]  # 禁用内置接收器
      processors: [batch]
      exporters: [nop]  # 禁用内置导出器

extensions:
  jaeger_storage:
    backends:
      query_storage:
        grpc:
          endpoint: elasticsearch:9200  # 指向存储服务
          tls:
            insecure: true

配置原理详解：通过将接收器和导出器设置为nop(空操作)组件，实现纯查询模式。存储连接配置在cmd/jaeger/config-query.yaml的jaeger_storage扩展中定义。

服务编排：使用Docker Compose快速启动

项目提供的docker-compose配置已包含完整服务定义，只需修改端口映射和依赖关系：

services:
  jaeger-query:
    image: jaegertracing/jaeger-query:latest
    volumes:
      - ./config-query.yaml:/etc/jaeger/config.yml
    ports:
      - "16686:16686"  # Web UI端口
      - "16687:16687"  # 健康检查端口
    environment:
      - SPAN_STORAGE_TYPE=elasticsearch
    depends_on:
      - elasticsearch

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    volumes:
      - ./otel-collector-config-connector.yml:/etc/otelcol/config.yaml
    ports:
      - "4317:4317"  # gRPC接收端口
      - "4318:4318"  # HTTP接收端口

启动服务栈：

docker-compose up -d

验证与故障排查

服务启动后，通过以下方式验证配置正确性：

1. 状态检查：访问http://localhost:16687/health确认查询服务健康
2. 数据验证：在Jaeger UI(http://localhost:16686)中执行搜索，验证是否能看到OTEL Collector发送的追踪数据
3. 日志查看：

# 查看OTEL Collector日志
docker-compose logs -f otel-collector

# 查看Jaeger查询服务日志
docker-compose logs -f jaeger-query

常见问题解决：

• 存储连接失败：检查config-query.yaml中jaeger_storage的endpoint配置，确保与存储服务地址一致
• 数据不显示：验证OTEL Collector的exporters配置是否正确指向存储，可参考项目中的config-spm.yaml示例
• 端口冲突：修改docker-compose.yml中的端口映射，避免与主机其他服务冲突

总结与最佳实践

通过OTEL Collector实现Jaeger纯查询服务，不仅降低了部署复杂度，还为多源数据整合提供了灵活方案。在生产环境中建议：

1. 资源限制：为查询服务设置CPU/内存限制，示例配置：

services:
  jaeger-query:
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G

2. 高可用部署：使用Kubernetes的StatefulSet部署查询服务，确保存储连接稳定性
3. 配置热更新：通过挂载配置文件实现动态调整，无需重启服务

项目中提供了完整的配置示例和部署脚本，可根据实际需求调整使用。收藏本文，下次部署Jaeger查询服务时即可快速参考实施。关注项目更新，下期将带来"多集群追踪数据聚合方案"。