京公网安备11010502063487号实测多机房路由:Envoy 优先级故障转移在 dc1 剩 75% 健康时仍全部留在 dc1(factor 140),剩 50% 时 30.2% 溢出到 dc2;dc1 全挂后主动检查约 1.86 s 切走、失败 172 个,什么检查都没配则一直不切(失败 535 个);就近让 p50 从 23.4 ms 降到 4.0 ms;nginx 的 backup 在 dc1 剩一半时一个都不接。
实测新实例预热:Envoy 1.39.3 的 slow_start_window 10 s 让新实例的流量占比从 6% 爬到 25%(不预热是一加入就 25%),冷启动期间的慢请求从 200 个降到 102 个但 p99 几乎没变;我写的客户端线性预热从 0% 起步慢请求更少(82 / 41 个);实例重启后 slow start 会重新生效。
实测 W3C traceparent:OpenTelemetry Python SDK 1.45.1 里三个服务的五个 span 共用一个 trace_id,每一跳 parent-id 是上一跳 CLIENT span 的 id,flags 是 03;中间一跳不传播就断链成两个 trace;baggage 不 attach 就传不下去;11 种 traceparent 里只有 2 种被延续,8 种另起新 trace。
实测上下文传播:Python 里 threading.Thread 和 ThreadPoolExecutor 都会丢上下文(子 span 另起新 trace),run_in_executor 同样;create_task、gather、to_thread 不丢;RabbitMQ 消息头带 traceparent 时消费者 span 是生产者的子 span(晚了 1014 ms 也一样),批量处理 3 条消息用 3 个 span link。
实测 span 树错乱的原因:下游时钟快或慢 20 ms,子 span 就在 100 / 100 个请求里晚结束、或在 99 / 100 个请求里比父 span 先开始;忘记 detach 让 6 个请求并成 1 个 trace;后台任务让整个 trace 的跨度(207.6 ms)是根 span 耗时(15.2 ms)的 13.6 倍;每个 span 丢 5% 时只有 1529 / 2000 个 trace 完整。
实测采样:头部采样 1% 时 49 个出错的 trace 一个都没留住(0 / 49),10% 也只留住 11 个;各服务用不同比例独立采样,3000 个 trace 里只有 308 个完整;Collector 的 tail_sampling 把出错和慢的 trace 全留住(49 / 49、95 / 95),输出文件只有全量的 399,817 / 2,761,015 字节,但出错 span 比 decision_wait 晚到时只留下 5 / 100。
实测 span 的属性、事件与状态:OpenTelemetry Python SDK 属性和事件各限 128 个,超限时丢掉最先加的(留下 72 到 199);OK 一旦设置就不能被 ERROR 覆盖;异常默认同时记事件并置 ERROR;每个属性序列化后约 41 字节;Collector 的 attributes / transform 处理器能删除密码、哈希邮箱、打码 URL 里的 token。
实测 OpenTelemetry Python SDK 的批量导出:接收端慢时默认队列 2048 丢了 1904 / 6000 个 span 且业务线程不受影响,队列 20000 则不丢;0.1 s 突发 10000 个只收到 3072 个;6 s 的短故障被重试和队列吸收(0 丢失),20 s 的故障丢了 2200 / 6000;os._exit 或被杀会丢掉队列里全部 span。
实测 OTLP 与 Collector:20000 个 span 经 gRPC 或 HTTP 都是约 207 字节/span,gzip 后约 41 字节;batch 处理器把 40 次写出合成 10 次但多等约 1 s;下游停 10 s 时 Collector 队列满会拒收,SDK 队列 200000 时只丢 200 个,默认 2048 时丢 50515 个。
实测指标类型:5 s 抓取间隔下 10 个 2 s 的尖峰 gauge 只碰上 4 个,counter 的 increase 19.9 s 对实际 20.3 s;counter 重启后直接相减是 1600、increase 3685(实际 4000);预先算好的 p99 取平均 282.2、加权 464.5,真实 508.7,histogram_quantile 732.6;对 gauge 用 rate 得到没有意义的 14.41。
实测直方图分位数:同一批样本下,默认桶的 p99 误差 −0%、×2 指数桶 −24%、只有两个桶 +38%;20 个线性桶的 p50 误差 +43% 比 9 个指数桶(+0%)还差;数据超出最大桶时 p99 只能返回 1000.0(平均值 5996.7);rate 窗口会改变 p50 看到的阶段;150 个标签组合 × 20 个桶是 3600 条序列。
实测基数爆炸:30 万条序列让 Prometheus 的 RSS 达到 890 MB(1000 条时 76 MB),抓取 137 ms;5 × 20 × 5 个标签组合 500 条序列,加上 user_id 变成 29180 条;request_id 每次变化时 60 s 里 head 序列数涨到 30,735 而“活”序列始终是 1,000;sample_limit 让整次抓取失败,labeldrop 让一万条序列悄悄合并成 6 条。