在微服务体系里，一次用户请求可能要经过网关、订单服务、库存服务、支付服务等多个环节，任何一处出现延迟或异常，排查起来都像大海捞针。Jaeger就是为解决这类问题而生的分布式追踪系统，它基于OpenTracing规范，把每个请求在各个服务中的执行片段记录成一个个Span，再将这些Span串联成完整的调用链路。而要让这套机制真正落地，核心问题就在于Span数据存到哪里、怎么存、存多久。本文将结合云服务器的实际部署场景，详细讲解Jaeger的Span存储配置方法。
一、先搞清楚Jaeger的架构和Span的流转过程
Jaeger的整体架构由几个核心组件构成：客户端SDK（jaeger-client）、代理（jaeger-agent）、收集器（jaeger-collector）、查询服务（jaeger-query）以及后端存储。应用程序通过OpenTracing的API创建Span，Span会被异步发送给本机或同网段的jaeger-agent，agent负责批量压缩后转发给collector，collector校验、清洗数据后写入后端存储，最后由jaeger-query对外提供查询界面和REST接口。
理解这个流程对存储配置非常重要。因为真正决定Span“存成什么样、存多久、查询快不快”的，是collector那一端的存储配置，而不是客户端。也就是说，你在云服务器上部署时，重点要操作的是collector和query的启动参数，业务代码里的OpenTracing Tracer初始化基本不需要感知存储类型的变化，这也是Jaeger架构解耦的好处。
目前Jaeger官方支持的存储后端包括：内存（memory，仅测试用）、Cassandra、Elasticsearch、Kafka（作为中间缓冲）、以及插件化的Badger和GrpcStorage。生产环境绝大多数团队会选择Elasticsearch，因为很多公司本来就有ELK体系，运维成本低；对写入量极大且查询模式固定的场景，Cassandra也是常见选择。
二、主流存储后端对比与选型建议
选存储不是拍脑袋的事，需要结合数据量、查询习惯和现有基础设施。下面这个表总结了三种常见方案的差异：
| 存储后端 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 内存（memory） | 零依赖、部署极简 | 重启丢数据、容量受限 | 本地开发、功能演示 |
| Elasticsearch | 全文检索强、生态成熟、易与ELK整合 | 需要维护ES集群、资源消耗较高 | 绝大多数生产环境 |
| Cassandra | 写入吞吐极高、线性扩展 | 运维门槛高、查询灵活性一般 | 超大规模、高写入场景 |
如果你的云服务器上已经跑着Elasticsearch集群，直接复用是最省事的方案，只需确保ES版本在5.x以上（建议7.x或8.x），并且给Jaeger单独建索引。如果追求极致写入性能且团队有Cassandra运维经验，Cassandra则更合适。无论选哪种，都不要在生产环境使用内存存储，数据丢失的风险不可接受。
三、配置Span存储到Elasticsearch的完整步骤
1. 部署collector时指定存储类型
假设你已经在云服务器上通过Docker或二进制方式安装了Jaeger，启动collector时的关键参数如下：
使用SPAN_STORAGE_TYPE指定存储类型为elasticsearch，并通过es.server-urls指向你的ES地址。例如通过环境变量方式配置：SPAN_STORAGE_TYPE=elasticsearch，ES_SERVER_URLS=http://你的ES内网IP:9200，ES_USERNAME和ES_PASSWORD填入认证信息（如果ES开启了xpack安全）。同时建议设置ES_INDEX_PREFIX，比如取名为jaeger，这样所有索引会以jaeger-开头，方便与业务索引区分和统一清理。
2. 分片与副本设置
Jaeger默认每个索引使用5个分片，但对中小规模来说往往过多。可以通过ES_NUM_SHARDS和ES_NUM_REPLICAS调整，比如日写入量在几十GB以内的场景，设成ES_NUM_SHARDS=3、ES_NUM_REPLICAS=1就足够了。分片过多会拖慢查询聚合速度，还会加重ES主节点的元数据负担，这是新手最容易踩的坑之一。
3. query服务的配置
jaeger-query需要用相同的存储参数启动，它才能读到collector写入的数据。也就是说，SPAN_STORAGE_TYPE和ES相关的环境变量在两个组件上要保持一致，否则界面上一片空白、查不到任何trace。另外记得开放16686端口，这是Jaeger UI的默认访问端口，在云服务器的安全组里放行后就可以通过浏览器访问了。
四、配置Span存储到Cassandra的方式
选择Cassandra时，SPAN_STORAGE_TYPE设为cassandra，并通过CASSANDRA_SERVERS指定Cassandra节点地址，CASSANDRA_KEYSPACE指定键空间名称，比如jaeger_v1。CASSANDRA_LOCAL_DC用于指定本地数据中心，在多云服务器跨可用区部署时尤其重要，配错会导致写入跨DC路由，延迟明显上升。
Jaeger首次连接Cassandra时会自动执行schema创建，也可以手动运行提供的DDL脚本。建议在生产环境先手动建好keyspace并设置合理的复制策略，比如NetworkTopologyStrategy加副本因子2或3，避免默认SimpleStrategy在节点扩容时带来的麻烦。此外，Cassandra模式下还可以开启保存时长相关的压缩策略，让旧数据自动降采样，节省磁盘。
五、数据保留策略与容量规划
Span数据的量级增长非常快。一个中等规模的微服务系统，每秒几千个Span很常见，一天下来轻松产生几十GB数据，所以保留策略必须提前规划。Elasticsearch方案下，Jaeger默认按天生成索引，配合ES的ILM（索引生命周期管理）策略即可自动删除过期索引，比如只保留7天热数据，超过后删除或转为快照。也可以用jaeger自身提供的es-index-cleaner工具定时清理，写成crontab每天执行一次。
Cassandra方案的保留时间由CASSANDRA_MODE相关参数以及TTL机制控制，写入时的默认TTL决定了数据的生命周期，一般设置为7到14天比较均衡。容量方面，建议在云服务器上为存储节点预留30%的磁盘余量，并开启磁盘使用率监控告警，阈值设在80%，防止索引写入被ES的磁盘水位线保护机制强制阻断。
六、常见问题排查
配置完成后如果UI上查不到数据，按这个顺序排查：第一，看collector日志有没有存储写入报错，认证失败和索引模板权限问题是高频原因；第二，检查业务服务到agent的UDP端口6831是否放行；第三，确认时间范围，Jaeger UI默认只查最近15分钟，如果你的测试请求在更早时间，记得调整查询窗口；第四，用ES的_cat/indices接口确认jaeger开头的索引是否在增长。另外，采样率配置也会影响数据量，如果是采样导致看不到trace，可以在客户端把采样策略临时调成全量验证链路是否通畅，验证完再调回 probabilistic 采样。只要存储这一层配置正确、容量规划到位，Jaeger就能长期稳定地为你的微服务体系提供全链路可观测能力。
Jaeger配置OpenTracing分布式追踪修改时间：2026-09-07 02:50:35