京公网安备11010502063487号实测配置的版本与回滚:Nacos 3.2.4 的每条 U 历史存的是修改之前的内容,回滚就是重新发布旧内容(历史多一条,回滚前的 v6 还在);删除记录里存着最后一版;不带 CAS 的并发编辑丢了一个字段,带 cas_md5 的会被拒绝;etcd 旧 revision 压缩后读不到(HTTP 400),Consul 带旧索引读得到的是当前值。
实测敏感配置:Nacos 3.2.4 默认明文存,改密码、删配置之后旧密码仍在 Derby 日志(6 次)和历史里,cipher- 前缀没有插件时也是明文;信封加密轮换主密钥只处理 DEK(100 条 1 MiB 数据:104,857,600 字节对 3,200 字节);双密钥轮换顺序做错时 400 或 1000 条记录读不出来;环境变量在 ps eww 里能看到。
实测多机房路由: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。