Zipkin 面试题

应用 (Instrumentation)
    │
    ├── Reporter.send(span) ── HTTP POST /api/v2/spans
    │
    ▼
Zipkin Collector
    │
    ├── 校验 traceId / spanId 格式
    ├── 写入 SpanStore
    │
    ▼
Storage (Cassandra / ES / MySQL)
    │
    ▼
Query Service ◄── Web UI (GET /api/v2/trace/{id})

docker run -d --name zipkin \
  -p 9411:9411 \
  openzipkin/zipkin

@Bean
public Brave brave() {
    return new Brave.Builder("order-service")
        .traceSampler(Sampler.ALWAYS_SAMPLE)  // 全量
        // 或
        .traceSampler(Sampler.NEVER_SAMPLE)
        // 或自定义
        .traceSampler(rateLimitingSampler(10))  // 10 req/s
        .build();
}

spring:
  sleuth:
    sampler:
      probability: 0.1   # 10% 概率采样
    propagation:
      type: B3          # B3 协议（默认）

public class BoundarySampler extends Sampler {
    private final Sampler delegate;
    
    @Override
    public boolean isSampled(TraceContext traceContext) {
        // 根 Span 决策，整条 Trace 保持一致
        if (traceContext.parentId() == null) {
            return delegate.isSampled(traceContext);
        }
        return traceContext.sampled() != null && traceContext.sampled();
    }
}

Zipkin:
  App → Reporter (HTTP POST) → Collector → Storage → UI

Jaeger (生产级):
  App → Jaeger Client → Agent (UDP **6831/6832**) → Collector → Kafka → Ingester → Storage → UI
                                                ↑                                    ↑
                                            缓冲削峰                            异步消费

CREATE TABLE zipkin_spans (
  trace_id_high BIGINT NOT NULL,
  trace_id      BIGINT NOT NULL,
  id            BIGINT NOT NULL,
  parent_id     BIGINT,
  name          VARCHAR(255),
  kind          VARCHAR(10),
  timestamp     BIGINT,
  duration      BIGINT,
  PRIMARY KEY (trace_id_high, trace_id, id, kind)
);

CREATE TABLE zipkin_annotations (
  trace_id_high BIGINT NOT NULL,
  trace_id      BIGINT NOT NULL,
  span_id       BIGINT NOT NULL,
  a_key         VARCHAR(255) NOT NULL,
  a_value       TEXT,
  a_type        INT,
  endpoint_service_name VARCHAR(255),
  PRIMARY KEY (trace_id_high, trace_id, span_id, a_key, timestamp)
);

CREATE INDEX idx_zipkin_annotations_ts
  ON zipkin_annotations (endpoint_service_name, a_type, trace_id_high, trace_id, span_id);

# 启动 Zipkin + ES
docker run -d --name zipkin \
  -e STORAGE_TYPE=elasticsearch \
  -e ES_HOSTS=http://es:9200 \
  -p 9411:9411 \
  openzipkin/zipkin

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
<!-- Web 组件自动埋点 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
    <groupId>io.zipkin.reporter2</groupId>
    <artifactId>zipkin-reporter-brave</artifactId>
</dependency>

spring:
  application:
    name: order-service          # 必填，对应 Zipkin localEndpoint.serviceName
  zipkin:
    base-url: http://zipkin:9411
    sender:
      type: web                  # web / kafka / rabbit
    compression-enabled: true     # gzip 压缩，减少网络带宽
  sleuth:
    sampler:
      probability: 0.1           # 10% 采样
    propagation:
      type: B3                   # 跨服务传递协议
    enabled: true

@Autowired
private Tracer tracer;

public void processOrder(Order order) {
    Span newSpan = tracer.nextSpan().name("validate-inventory").start();
    try (Tracer.SpanInScope ws = tracer.withSpan(newSpan)) {
        // 业务逻辑
        newSpan.tag("order.id", order.getId());
        inventoryService.check(order);
    } catch (Exception e) {
        newSpan.error(e);
    } finally {
        newSpan.end();
    }
}

span.tag("user.id", userId);          // 搜索时可按 user.id 过滤
span.event("cache.miss");              // 事件记录
span.error(exception);                 // 自动记录异常堆栈

b3: 0af7651916cd43dd-b7ad6b7169203331-8448eb211c80319-1
     │                │                │                │
     │                │                │                └─ Sampled (0/1/d)
     │                │                └─ Parent Span ID (可选)
     │                └─ Span ID
     └─ Trace ID

# Spring Boot 同时启用 B3 与 W3C
spring:
  sleuth:
    propagation:
      type: B3,W3C    # 双协议注入，按 Header 优先级解析

# otel-collector-config.yaml
receivers:
  zipkin:
    endpoint: 0.0.0.0:9411

exporters:
  otlp:
    endpoint: jaeger:4317

service:
  pipelines:
    traces:
      receivers: [zipkin]
      exporters: [otlp]

<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-zipkin</artifactId>
</dependency>

SpanExporter zipkinExporter = ZipkinSpanExporter.builder()
    .setEndpoint("http://zipkin:9411/api/v2/spans")
    .build();

SdkTracerProvider tracerProvider = SdkTracerProvider.builder()
    .addSpanProcessor(SimpleSpanProcessor.create(zipkinExporter))
    .build();

# otel-collector 配置
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  zipkin:
    endpoint: http://zipkin:9411/api/v2/spans
    format: json

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [zipkin]

// 使用 zipkin-reporter-otel
@Bean
public Reporter<Span> zipkinReporter() {
    return OpenTelemetrySpanExporter.create("http://zipkin:9411/api/v2/spans");
}

阶段 1: 现状评估
  ├── 列出所有使用 Zipkin 客户端的服务
  ├── 统计 SDK 版本、协议类型（B3 / Thrift）
  └── 评估存储后端类型与数据量

阶段 2: 引入 OTel SDK（双写过渡）
  ├── 应用层 OTel SDK 初始化
  ├── 保留 zipkin-reporter 兼容旧版
  ├── 部署 OTel Collector 接收 OTLP
  └── 灰度 10% 流量验证数据一致性

阶段 3: 协议统一
  ├── 全量切流 OTel SDK
  ├── 通过 Collector 桥接至 Zipkin
  ├── 验证 traceId / spanId / parentId 一致
  └── 关闭 zipkin-reporter 直连

阶段 4: 后端演进
  ├── 保留 Zipkin（成本低、UI 简洁）
  ├── 或迁移至 Jaeger / Tempo（OTel 原生）
  └── 长期方案：OTel SDK + Tempo + Grafana

# Zipkin Server 启动配置
STORAGE_TYPE=elasticsearch
ES_HOSTS=http://es:9200

# Collector 端通过 Kafka 异步上报
KAFKA_BOOTSTRAP_SERVERS=kafka:9092
KAFKA_TOPIC=zipkin-spans
ZIPKIN_COLLECTOR_KAFKA_ENABLED=true

// 应用端配置（Spring Boot）
spring:
  zipkin:
    sender:
      type: kafka
    kafka:
      bootstrap-servers: kafka:9092
      topic: zipkin-spans

// 1. 自适应采样：核心接口高概率，非核心低概率
@Bean
public Sampler customSampler() {
    return new CompositeSampler()
        .add("/api/payment/**", 1.0)        // 支付链路 100%
        .add("/api/health", 0.0)            // 健康检查 0%
        .defaultRate(0.05);                 // 其他 5%
}

// 2. 精简 Tags，避免记录敏感与冗余信息
span.tag("order.id", order.getId());
// 不要做：
// span.tag("request.body", jsonString);  // 体积大、可能含敏感数据

// 索引模板
{
  "index_patterns": ["zipkin:span-*"],
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 1,
    "refresh_interval": "10s"
  },
  "mappings": {
    "properties": {
      "traceId": { "type": "keyword" },
      "name": { "type": "keyword" },
      "timestamp_millis": { "type": "long", "index": false },
      "tags": { "type": "object", "dynamic": true }
    }
  }
}

# 部署多个 Zipkin Collector 实例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: zipkin-collector
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: zipkin
        image: openzipkin/zipkin
        env:
        - name: STORAGE_TYPE
          value: elasticsearch
        - name: ES_HOSTS
          value: http://es:9200

排查步骤：
1. Zipkin UI 搜索 serviceName=order-service，按 duration 降序
2. 发现 span "GET /api/inventory" 耗时 4.8s，占比 95%
3. 展开 span 查看 tags：http.status_code=200 但 db.statement 显示
4. 继续下钻 "SELECT * FROM inventory WHERE sku=?" 耗时 4.5s
5. 查看对应 service=inventory-service 的其他 Trace
6. 发现同一时间窗口存在慢 SQL + 连接池等待

根因：inventory-service 数据库缺失 sku 联合索引，全表扫描导致
解决：CREATE INDEX idx_inventory_sku ON inventory(sku)
验证：修复后 P99 下降至 180ms

排查步骤：
1. Zipkin UI 搜索 tags.error=true，serviceName=order-service
2. 错误 Trace 中定位到 span "POST payment-service" 抛异常
3. 查看 annotation：cs 存在但缺失 cr，duration 异常短
4. 推断为客户端超时（connectTimeout=500ms, readTimeout=2s）
5. 继续下钻：payment-service 在该时间窗口 CPU 100%
6. 查看 payment-service 自身 Trace，发现大量 Span "fegin-retry"

根因：payment-service 因 GC 频繁（Young GC 200ms+）处理变慢，
     触发客户端超时与重试，雪崩效应
解决：
  - 调整 JVM 堆内存（-Xmx 4g → 8g）
  - payment-service 接口降级（非关键查询走缓存）
  - 客户端禁用自动重试（feign.client.config.default.connectTimeout=2000,readTimeout=5000）

现象：UI 页面打开后无响应，依赖图加载失败
排查：
1. 浏览器 Network 查看 /api/v2/dependencies 请求超时 30s
2. Zipkin Server 日志显示：QueryService 慢查询
3. 后端 MySQL 慢日志：SELECT COUNT(*) FROM zipkin_spans_dependencies 全表扫描
4. 存储后端存储了 90 天历史数据，依赖计算范围过大

根因：Zipkin 默认按 serviceName 全量计算依赖，数据膨胀导致超时
解决：
  - 缩短依赖分析时间窗口（UI 限定 24h）
  - MySQL 改 ES，利用 ES 聚合计算能力
  - 配置数据保留策略：7d 后自动清理（zipkin.storage.strict-trace-id-ttl=true）

现象：调用链 order-service → payment-service（跨机房），
     UI 上 payment-service Span 缺失
排查：
1. 抓取 order-service 出站请求 Header
2. 发现 X-B3-TraceId 存在，但 X-B3-SpanId 为空
3. 检查 order-service 网关（Spring Cloud Gateway）配置
4. 网关未开启 trace propagation，未透传 B3 Header

根因：Spring Cloud Gateway 与下游服务使用 Sleuth 时，需在 Gateway
     Filter 中显式传递 Header
解决：

**案例五：高 QPS 场景下应用线程阻塞**

**生产排查工具链：**

| 工具 | 用途 |
|------|------|
| **Zipkin UI** | Trace 时间线、Span 详情、依赖图 |
| **Zipkin API** | `GET /api/v2/trace/{traceId}` 编程化查询 |
| **TraceID 关联日志** | Sleuth 自动注入 MDC，ELK / Loki 可按 traceId 聚合 |
| **Metrics 联动** | Prometheus + Zipkin Tag serviceName 关联指标 |
| **火焰图** | SkyWalking / Jaeger 支持，与 Zipkin 数据互通 |

**核心原则：**

- 跨服务问题优先看 Trace，单服务问题优先看 Metrics。
- 关注 Span duration 占比，找到长尾 Span 即找到瓶颈。
- 生产环境开启 `tags.error=true` 与 `duration > 阈值` 告警。
- 始终为每个服务注入 `serviceName` + `host` + `env` 标签，便于多环境隔离。