SamplingFilter 在 logback-spring.xml 中未生效，因 Spring Boot 日志初始化早于上下文加载，需通过 ApplicationRunner 或 @PostConstruct 动态注册；推荐自定义 Filter 基于 traceId 一致性哈希采样。
为什么 logback-spring.xml 里配了 SamplingFilter 却没生效
Spring Boot 默认用 Logback，但直接在 logback-spring.xml 里加 SamplingFilter 很可能被 Spring Boot 的自动配置覆盖。根本原因是：Spring Boot 在启动时会提前初始化日志系统，此时上下文还没加载完，自定义 filter 容易被跳过或顺序错乱。
- 必须把采样逻辑移到
LoggerContext初始化完成之后，推荐方式是用ApplicationRunner或@PostConstruct动态注册 filter - 避免在
<appender></appender>内部嵌套<filter class="ch.qos.logback.core.filter.SamplingFilter"></filter>—— 这个类不支持动态阈值，且默认只对 WARN/ERROR 生效 - 更稳妥的做法是自定义
Filter继承Filter<iloggingevent></iloggingevent>，并在decide()里接入业务标识（如 traceId）做一致性哈希采样
OpenTelemetry SDK 的 TraceIdRatioBasedSampler 和日志采样怎么联动
全量日志采集不是“所有日志都打”，而是“所有请求链路中，只要 trace 被采样，其关联日志也应保留”。TraceIdRatioBasedSampler 控制的是 span 上报，但日志本身没 trace 上下文就无法联动。
- 确保日志 MDC 中已注入
trace_id和span_id，Spring Boot 项目需确认spring.sleuth.enabled=true或otel.instrumentation.spring-scheduling.enabled=true - 不要依赖
TraceIdRatioBasedSampler直接控制日志输出；应在日志 appender 层做判断：检查 MDC 中trace_id是否非空，再用相同 ratio 做二次哈希决定是否写入 - 注意 OpenTelemetry Java SDK v1.30+ 把
TraceIdRatioBasedSampler改为只读实例，不能 runtime 修改 ratio，需在SdkTracerProviderBuilder阶段就固定
ELK 链路日志爆炸时，filebeat 的 processors 能否替代服务端采样
可以减负，但不能替代。Filebeat 的 drop_event 或 condition 处理是在日志落地磁盘后、发送前做的，它不感知 trace 上下文，也无法保证同一次请求的日志原子性丢弃。
- 常见错误：用
regexp匹配"level":"DEBUG"就 drop，结果把关键调试日志和慢 SQL 日志一起干掉 - 真正可用的策略是结合
dissect提取trace_id，再用script处理器做一致性哈希（例如hash_mod(trace_id, 100) ），但要求 Filebeat ≥ 7.16 且启用 Lua 支持 - 性能影响明显：每个事件多一次字符串解析 + 哈希计算，QPS 超 5k 时 CPU 占用上升 20%+，不如在应用层预筛
log4j2 的 RoutingAppender 怎么实现按 traceId 分流到不同 Kafka topic
这是微服务里最实用的分流方案之一，但容易卡在 RoutingAppender 的 key 解析和子 appender 生命周期上。
- 必须用
ThreadContext（而非 MDC）传trace_id，否则异步线程（如 Dubbo callback、CompletableFuture）里会丢失 -
key字段要设成$${ctx:trace_id}，但若 trace_id 为空，RoutingAppender 会 fallback 到默认 route，得显式配置defaultRoute指向丢弃 appender - Kafka appender 子项里别开
async，否则不同 trace_id 的日志可能混进同一个 batch，破坏 topic 隔离性；改用failoverappender 包一层兜底
