【Cilium / eBPF】可观测与运维口径：cilium status、metrics 语义与 bpftool 边界
内容提要
本文介绍Cilium v1.20.0可观测性排障方法，强调先选观测层（status、Hubble、metrics、bpftool），再读字段语义。区分控制面健康与数据面丢包，指出status全绿不等于策略放行，Hubble环满非丢包。建议用cilium-dbg解读BPF map，避免bpftool误读，并给出业务症状到观测层的映射及常见误判。
延伸解读
观测层选择：先定层，再读字段
文章强调排障时先选观测层，再读字段语义。不同层回答不同问题：cilium status 适合判断控制面是否大体健康，但不适合定位单条流被拒；Hubble flow 适合看单流 verdict 和 drop reason，但不适合长期趋势；metrics 适合看趋势和压力，但不适合亚秒级归因。业务症状应先映射到对应层，避免用 status 全绿否定业务问题。
status 全绿不等于策略放行
cilium status 的 OK 只表示子系统自报健康，不展开每条 CNP 的放行细节。常见误读包括：Hubble 环满被当成丢包（实为观测缓冲饱和）、kube-proxy replacement 正常不等于后端非空、加密启用不等于所有路径生效。status 应作为进入下一层的闸门，而非业务连通性的证明。
bpftool 与 cilium-dbg 的边界
bpftool 能看内核挂载和 map 原始数据，但不懂 Cilium 语义，易误读二进制 value。排查 Service 后端、策略、CT 等应使用 cilium-dbg bpf 子命令，它按 Cilium 数据结构解码。bpftool 仅作为确认程序挂载的旁证，且严禁用 bpftool map update 手工修改 Cilium map，否则会被控制面覆盖或打穿状态。
指标全绿仍丢包的常见错位
文章列出多种误判：agent metrics 绿不代表 Hubble metrics 在刮（两套开关和端口）；drop 计数升高不一定是 NetworkPolicy，需看 reason；L7 Envoy 指标绿不代表 L3/L4 策略绿；ClusterMesh 摘要 Connected 不代表远端 identity 已同步。排障时需对齐时间窗口，避免用此刻的 status 否证十分钟前的 DROPPED。
Q&A
Cilium 排障时，应该按照什么顺序选择观测层？
先选观测层，再读字段语义。通常先用 cilium status 判断控制面是否健康，再用 Hubble 定位具体流的 verdict 和 drop reason，最后用 metrics 和 BPF map 判断是否系统性压力。
cilium status 全绿是否代表网络策略已正确放行？
不代表。cilium status 只是控制面健康摘要，不展开每条 CNP 的策略细节。业务超时但 status 全绿是常见情况，需要进一步用 Hubble 查看具体流的 verdict。
Hubble flow 环满是否意味着数据面丢包？
不是。Hubble flow 环满只表示事件缓冲饱和，旧事件被覆盖，观测丢失，不等于数据面丢包。
bpftool 和 cilium-dbg bpf 命令有什么区别？
bpftool 是通用 eBPF 工具，能查看程序挂载和 map 原始数据，但不理解 Cilium 的 identity/policy 语义；cilium-dbg bpf 命令则按 Cilium 数据结构解读 Service、策略、CT 等，更适合排障。
业务症状是偶发连接超时，应该先看哪些观测？
先看 Hubble drop reason 和 CT GC 指标，再看 identity 是否在窗口内变化。
Cilium 的 Prometheus 指标中，cilium_bpf_map_pressure 升高说明什么？
说明 BPF map 压力大，可能接近容量上限，策略查找可能溢出或降级。应检查宽 CIDR 或大 selector，而不是直接重启节点。
为什么说 cilium status OK 不等于策略按意图放行？
因为 cilium status 只是控制面健康摘要，不展开每条 CNP 的策略细节。策略是否放行需要查看 Hubble 的 verdict 或 policy map。
在 Cilium 排障中，如何区分控制面健康和数据面丢包？
控制面健康看 cilium status 和 cilium-dbg status --verbose，数据面丢包看 Hubble flow 的 verdict 和 drop reason。两层同时绿但业务仍挂，才需下钻加密与 Service 黑洞。
