【Cilium / eBPF】Hubble 信号：flow 字段语义与「指标全绿仍丢包」
内容提要
本文讨论Cilium/Hubble可观测性：Hubble flow提供连接级事件与verdict，metrics提供聚合计数，二者口径不同。全绿面板不代表无丢包，可能丢在未观测平面。排障应先定观测点，区分FORWARDED/DROPPED/REDIRECTED，注意采样、高基数、Relay延迟等盲区，结合Cilium agent与主机指标综合判断。
延伸解读
全绿面板为何仍丢包：观测点与口径错位
Hubble flow 与 metrics 是两套独立管线：flow 是事件流，metrics 是聚合计数，二者采样、过滤、导出路径不同。面板全绿只说明你选的聚合序列未报警，不证明数据面每一跳成功。丢包可能发生在未观测平面，如节点网卡、云安全组、应用层，或流量未经过期望的 hook 点。排障应先明确观测点，再读 verdict，避免把 REDIRECTED 当业务成功，或把 FORWARDED 当最终投递成功。
flow 字段语义：排障坐标系的关键
Hubble flow 的 source/destination 是端点身份视图，含 namespace、pod、identity，不能只盯 IP；verdict 分层中 FORWARDED 不保证对端应用读完，DROPPED 必须读 drop reason，REDIRECTED 常指向 L7 代理。traffic_direction 是相对 endpoint 的 ingress/egress，与南北向口语不同。Type/Subtype 区分 L3/L4 与 L7，未启用 L7 可见性时，用 L3 流解释 HTTP
metrics 与 flows 的口径差：何时绿而业务红
Hubble metrics 如 drop_count_total 按 reason 聚合，flows_processed_total 计的是被 Hubble 处理的 flow 事件，不是网卡 pps 或应用成功数。未启用 drop metric、采样过滤掉某 namespace、丢在加密/路由/云 LB、或应用层失败（如 HTTP 403/429）都可能导致 metrics 绿而业务红。L7 拒绝记在 HTTP 指标或 Envoy，L3/L4 drop 不变。瞬时 drop 被平均掉，控制面指标才有尖刺。
排障顺序与观测纪律：先定平面再拉 flow
推荐顺序：先定平面（东西向、南北向、跨集群），再看 Cilium 健康（agent ready、KPR/加密模式），然后看聚合 drop reason，最后拉 flow 按 namespace、verdict、identity 过滤。若 flow 为 FORWARDED，下钻节点网卡、对端应用、Service 后端。注意 Relay 延迟、事件背压会导致 flow 缺口而 metrics 少计；高基数标签可能打垮 Prometheus。排障记录应写下观测时间戳、时区、节点本地还是 Relay。
Q&A
为什么Cilium/Hubble面板全绿但业务仍然丢包？
因为Hubble flow和metrics是两种不同的信号：flow是带verdict的事件流，metrics是按标签聚合的计数。二者采样、过滤、导出路径不同，且metrics全绿只说明你选的聚合序列没报警，不证明数据面每一跳都成功。丢包可能发生在未观测平面，如加密/路由/云LB、应用层，或由于采样/过滤掉了某些namespace。
Hubble flow中的verdict字段有哪些取值，分别代表什么？
verdict字段主要有FORWARDED、DROPPED、REDIRECTED和AUDIT。FORWARDED表示该观测点允许继续，但不保证对端应用已读完；DROPPED表示在Cilium数据面主动丢弃，必须读drop reason；REDIRECTED常指向代理（L7），最终成败在Envoy/应用；AUDIT模式记录本应拒绝但仍放行的流量，用于演练，不能当成生产已强制。
Hubble metrics和flows在排障中各自擅长什么？
flow擅长归因，回答“这一次为何如此”，例如从谁到谁、verdict、drop reason；metrics擅长告警与容量，回答“这一类是否变多”，例如丢包率趋势、按reason聚合。用metrics回答“哪条CNP拒了这个五元组”不够，用flow洪水回答“过去24h丢包趋势”会贵。
在Cilium排障中，如何正确使用Hubble flow和metrics？
推荐顺序：先定平面（东西向、南北向、跨集群）；看Cilium健康（agent ready、KPR/加密/策略模式）；看聚合drop reason（若启用Hubble drop，按reason排序）；拉flow按namespace、verdict、identity过滤；若flow为FORWARDED，下钻节点网卡、对端应用、Service后端、加密。同时注意观测点相对加密的位置，避免把密文隧道误当成业务五元组。
Hubble Relay和采样对观测有什么影响？
Hubble Relay聚合并提供集群查询面，但节点Hubble崩溃或Relay落后时，metrics刮取若仍打在存活实例上，会出现局部绿、全局盲区。采样可能丢掉稀有deny，高基数标签（如为每个source_ip/destination_pod打开labelsContext）会撑爆Prometheus，导致故障时没有可用时间序列。工程纪律是默认用粗标签，故障时临时加细过滤的flow查询。
为什么说“Hubble没有DROP”不能反证“没有NetworkPolicy问题”？
因为流量可能没走到强制点（如hostNetwork流量不经期望hook），或verdict在L7（如HTTP 403/429），或Hubble事件丢失（背压导致flow缺口）。所以“Hubble没有DROP”只说明Cilium数据面没主动丢弃，不代表没有策略问题。
Cilium中如何区分Policy denied和Service黑洞导致的连接失败？
Policy denied通常表现为DROPPED + drop_reason为Policy denied，优先看策略编译与Identity窗口；Service黑洞常先有连接失败而非deny，flow上可能看不到预期backend身份，需检查Service/LB map与路由。
