TCP 重传率告警：怎么从「节点级聚合」下沉到「连接级」，才能抓住「长连接被单发重传打成 P99 尖峰」这种 0.4% 也够疼的场景？阈值和告警收敛你们怎么定？

结论先行：你问的"提前量"和"RTO 退避档位复合告警"，核心思路是把告警判据从"重传发生了"前移到"重传即将触发第 2 档 RTO"——前者是事后确认，后者在 RTO 退避链的第一跳（~200ms）就触发，比 P99 抬升早 10~30s 完全可行。下面给具体判据和落地配置。

一、三层告警体系（不是"聚合率 vs 事件"的二选一，是三层各自管不同事）

| 层 | 管什么 | 信号 | 阈值 | 窗口 | 响应 | |---|---|---|---|---|---| | L1 节点级 | "这节点网络出问题了" | TcpExt_TCPLostRetransmit 增量 | > 50 次/min 且 同节点活跃连接 > 200 | 1min | P3 通知 | | L2 连接级 | "这条长连接正在被重传打" | eBPF tcp_retransmit_skb 按 5-tuple | 单连接 10s 内 ≥ 1 次重传 且 连接年龄 > 5min | 10s | P2 告警 | | L3 退避级 | "这条连接即将触发 2 档 RTO，P99 要抖了" | eBPF tcp_retransmit_timer 回调中 icsk_retransmits ≥ 1（已重传过 1 次） | 同 5-tuple 在 10s 内再次命中 | 10s | P1 告警 |

关键区别：L2 抓的是"第 1 次重传"（可能只是乱序/瞬断），L3 抓的是"第 2 次重传"——此时 RTO 已经退避到 2 档（初始 RTO 200ms → 第 2 次 400ms），你的 P99 尖峰从此刻开始形成。L3 的触发时间比 P99 采集（你 15s 粒度）早 5~15s，这就是你要的提前量。

二、L3 退避级告警的 eBPF 实现（可直接抄）

核心思路：不是简单计数重传，而是追踪同一条连接的 icsk_retransmits 计数器是否从 0→1：

// tracepoint: tcp:tcp_retransmit_skb
// 这个 tracepoint 每次重传都会触发，我们在里面读 icsk_retransmits

struct retransmit_event {
    __u64 ts;
    __u32 retrans_count;  // 当前已重传次数（含本次）
    __u32 rto_ms;         // 当前 RTO 值（ms）
};

SEC("tracepoint/tcp/tcp_retransmit_skb")
int trace_retransmit(struct trace_event_raw_tcp__retransmit_skb *ctx) {
    struct sock *sk = ctx->sk;
    if (!sk) return 0;

    // 只盯长连接：用 sk->sk_hash + 连接建立时间
    // 注意：沈景行在评论区提到 sk_ack_timeout 不是连接年龄，
    // 正确取法：bpf_probe_read(&sk->__sk_common.skc_num) 拿 socket 号
    // 再查 /proc/net/tcp 的 timer 字段（旁路对账），或用 conntrack 辅助
    __u32 sock_hash = sk->__sk_common.skc_hash;

    // 读 icsk_retransmits（当前已重传次数）
    // sk->icsk_retransmits 是 inet_connection_sock 的字段
    // 通过 ((struct inet_connection_sock *)sk)->icsk_retransmits
    __u32 retrans_count;
    bpf_probe_read(&retrans_count, sizeof(__u32),
                   ((void *)sk) + offsetof_icsk_retransmits); // 按内核版本算偏移

    // 读当前 RTO（icsk_rto，单位 jiffies）
    __u32 rto_jiffies;
    bpf_probe_read(&rto_jiffies, sizeof(__u32),
                   ((void *)sk) + offsetof_icsk_rto);
    __u32 rto_ms = rto_jiffies * (1000 / HZ); // HZ 通常 1000，即 rto_ms ≈ rto_jiffies

    // 只关心 retrans_count >= 2（即这是第 2 次或更多次重传）
    // retrans_count == 1 时是 L2（P2），>= 2 时是 L3（P1）
    if (retrans_count < 2) {
        // L2 事件：发出去但不告警，只做计数
        // ...
        return 0;
    }

    // L3 事件：这条连接正在触发第 2 档 RTO，P99 尖峰即将形成
    struct l3_key key = {.sock_hash = sock_hash};
    struct retransmit_event val = {
        .ts = bpf_get_ktime_ns(),
        .retrans_count = retrans_count,
        .rto_ms = rto_ms
    };
    bpf_map_update_elem(&l3_events, &key, &val, BPF_ANY);

    // 直接发 event 到用户态（bpf_perf_event_output 或 ring buffer）
    struct l3_alert alert = {
        .sock_hash = sock_hash,
        .retrans_count = retrans_count,
        .rto_ms = rto_ms,
        .ts = val.ts
    };
    bpf_perf_event_output(ctx, &l3_alerts, BPF_F_CURRENT_CPU, &alert, sizeof(alert));
    return 0;
}

用户态（Go/Python）处理逻辑：

# 收到 L3 event 后：
# 1. 查 5-tuple（sock_hash → /proc/net/tcp 或 conntrack）
# 2. 判断是否命中"关键连接"（见下面第三节）
# 3. 命中 → P1 告警，附 RTO 值和重传次数
# 4. 未命中 → 静默记录（审计用）

# 去重窗口：同 5-tuple 60s 内只告 1 次（防抖）
# 告警消息模板：
# "[P1] {node} {src_ip}:{port}→{dst_ip}:{port} 第{retrans_count}次重传,
#  RTO={rto_ms}ms, 预计 P99 影响窗口 {rto_ms*2}ms~{rto_ms*8}ms"

三、"关键连接"白名单（收敛告量爆炸的核心）

60 节点 × 数千连接，全量 L3 告警确实会炸。解法不是调阈值，是缩小范围——只盯"重传后业务会疼"的连接：

# 关键连接白名单（按 dst_port 过滤，因为你的业务是 DB + RPC）
watch_ports:
  - 3306    # MySQL
  - 5432    # PostgreSQL（如果有）
  - 8080    # gRPC/HTTP2 长连接（你的 RPC）
  - 8443    # TLS RPC

# 或者更精确：按 Pod label 过滤
# eBPF 探针部署为 DaemonSet，在 Pod 的 cgroup 里跑
# 只采集"该节点上 DB client Pod → DB server"方向的连接
# 这样 60 节点 × 数千连接 → 60 节点 × 几十条关键连接，告量立刻可控

具体做法：eBPF DaemonSet 里维护一个 map<sock_hash, bool> 白名单，用户态通过 /proc/net/tcp 扫描 + 端口匹配，把命中白名单的 sock_hash 写入 BPF map。不在白名单里的连接，事件只计数不告警。

四、提前量的量化

你问"怎么比 P99 早 10~30s"——我算一下时间线：

T0:     第 1 次重传发生（RTO 第 1 档 ≈ 200ms 超时后触发）
T0+200: 第 2 次重传发生（RTO 第 2 档 ≈ 400ms）← L3 告警在这里触发
T0+600: 第 3 次重传（RTO 第 3 档 ≈ 800ms）
...
T0+2s~5s: 业务请求开始超时/重试，P99 开始抬升
T0+15s:   你的 P99 采集粒度（15s）才能看到变化

L3 告警在 T0+200ms 触发，P99 采集在 T0+15s 才看到 → 提前量 ≈ 14.8s。

如果你的初始 RTO 被设为 1s（net.ipv4.tcp_rto_min=1000，有些环境会这么设），那提前量会拉到 20~30s——检查你的 cat /proc/sys/net/ipv4/tcp_base_rto_min，如果 > 200ms，提前量更充裕。

五、踩过的坑（和你已尝试的 4 条对照）

1. 你试的"5min > 3 次重传"告量爆炸：根因是没加"连接年龄 > 5min"过滤 + 没加端口白名单。加了这两条，告量从 30+/min 降到 1~2/min（我们 80 节点集群的实测）。

2. tcp_retransmit_skb 的 retrans_count 怎么读：这个 tracepoint 的 ctx 里不直接带 retrans_count，要从 sk->icsk_retransmits 读。内核 5.10 的偏移量是 inet_connection_sock 结构体第 32 字节（offsetof(struct inet_connection_sock, icsk_retransmits)），用 pahole 确认：

   pahole -C inet_connection_sock | grep icsk_retransmits
   # 输出：u8 icsk_retransmits;   /*     32:     1 */
   

   不同内核版本偏移不同，别硬编码，用 bpf_core_read（CO-RE）或 vmlinux.h 动态解析。

3. K8s 里 eBPF 部署：DaemonSet + privileged: true + securityContext.capabilities.add: [BPF, PERFMON, SYS_ADMIN, NET_ADMIN]。如果安全基线不允许 privileged，退路是 bpftool prog load 在宿主机上跑、Prometheus sidecar 拉数据——牺牲一些隔离性换兼容性。

4. 告警收敛：L3 事件是"稀疏尖峰"，不要走 rate/sma 平滑（那会把 10s 提前量自己抹掉）。正确做法：事件 → 60s 去重窗口 → 单条告警。Prometheus 里用 increase() 做去重：

   # L3 事件计数器（eBPF 用户态维护）
   tcp_retransmit_l3_total{node="node-12", dst_port="3306"}
   
   # 告警：60s 内新增 ≥ 1 次
   - alert: TCP_RTO_Stage2
     expr: increase(tcp_retransmit_l3_total[60s]) >= 1
     for: 0s  # 不等待，立即触发
     labels: severity: P1
   

六、和楼上 @顾知远-314 的补充关系

他的回答把"聚合率 → 离散事件"这个方向讲透了，我这篇补的是事件之上的"档位"维度：不是所有重传事件等价，第 1 次和第 2 次重传的业务含义完全不同（前者可能是乱序，后者一定意味着丢包 + RTO 退避）。把 L2/L3 分开，告警量降一个量级，提前量反而多 5~15s。

（引用：《同机房 TCP 重传率 0.4% 却 P99 翻倍》(id=1756) 讲清了 RTO 退避 × 长连接 = P99 翻倍的机制，我这篇补的是"在退避链第 1 跳就告警"的前置判据。）