net.DialTimeout仅测TCP三次握手延迟，非业务响应延迟，云环境受NAT/SLB/安全组影响大，宜用于healthz探活；真实延迟需用自定义http.Transport+RoundTripper打点，跨地域强制MaxIdleConnsPerHost=1，监控用直方图分桶+histogram_quantile按region聚合。
用 net.DialTimeout 测单次 TCP 连通延迟，但别当真用它报“服务延迟”
它测的是三次握手完成时间，不是业务响应延迟，更不反映真实网络抖动。云环境里 NAT、SLB、安全组策略都可能让这个值忽高忽低，甚至超时≠网络差（比如后端进程卡住但端口还开着）。
实操建议：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只用于快速探活，比如
healthz端点连通性检查 - 超时设得比业务 RTT 高一点，比如
500 * time.Millisecond，避免误判 - 别拿它和
http.Client的Timeout混用——后者含 DNS 解析、TLS 握手、请求发送、响应读取全流程 - 跨地域场景下，务必固定使用 IPv4 或 IPv6（
tcp4/tcp6），否则某些云厂商的双栈解析会引入不可控延迟
真正要监控的延迟，得走业务链路打点：用 http.Client + RoundTripper 拦截
云原生服务多数走 HTTP，真实延迟藏在请求发出到响应头到达之间。直接用默认 http.Client 会漏掉 DNS 和连接复用的影响，必须自定义 RoundTripper。
常见错误现象：Client.Timeout 触发时你不知道是卡在 DNS、建连、TLS 还是后端处理上。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用
&http.Transport{DialContext: ...}包裹自定义拨号逻辑，分别记录dnsStart/dnsDone、dialStart/dialDone - 在
RoundTrip返回前，用resp.Header.Get("Date")或服务端注入的X-Request-Id关联上下游耗时（注意时钟漂移） - 跨地域调用时，强制关闭连接复用：
Transport.MaxIdleConnsPerHost = 1，否则复用旧连接会掩盖新建链路的高延迟问题
ping 和 traceroute 在容器/K8s 里基本没用，换 goping 或 mtr 替代
K8s Pod 默认没 ICMP 权限，exec.Command("ping", ...) 十有八九失败；traceroute 更依赖 raw socket，非特权容器直接被拒。硬塞 hostNetwork: true 又破坏隔离性。
实操建议：
- 用纯 Go 实现的
goping库（支持 UDP/ICMP 两种模式），编译进镜像时加cap_net_raw而非全开 hostNetwork - 想看路径瓶颈？改用
mtr的 JSON 输出模式：mtr --json --report-cycles 3 example.com，再用 Go 解析hops数组里的avg字段 - 别信容器内
ping延迟——宿主机网卡、CNI 插件（如 Calico 的 BPF）、甚至 VPC 路由表都可能扭曲结果
聚合延迟数据时，histogram_quantile 比平均值有用，但分位数选错等于白算
Prometheus 里用 rate() 算 QPS 没问题，但延迟直出 avg_over_time(duration_seconds[1h]) 会把 99% 的请求拖慢的毛刺抹平，看不出尾部延迟恶化。
实操建议：
- 上报延迟必须用直方图（
prometheus.HistogramVec），桶区间按跨地域实际 RTT 设：比如国内 20ms、新美 150ms、东京 200ms，则桶设为[]float64{50, 100, 200, 400, 800} - 查 P99 用
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1h]))，注意分母必须是带_bucket后缀的指标 - 不同地域服务必须打不同
region标签，否则quantile会跨区混算——上海节点连新加坡和连杭州的延迟不能揉一起
跨地域延迟监控最难的不是采集，是区分清楚：你到底想回答「链路是否通」、「用户感受到多慢」，还是「哪个中间节点拖了后腿」。这三个问题对应完全不同的埋点位置和指标口径，混着用只会让告警越来越不准。
