【Cilium / eBPF】Hubble 信号：flow 字段语义与「指标全绿仍丢包」

值班看到 Grafana 里 Cilium / Hubble 面板全绿，同时业务喊丢包——这两种信号并不矛盾。Hubble 的 flow 是带 verdict 的事件流；metrics 是按标签聚合的计数。二者采样、过滤、导出路径不同，和「网卡丢包 / 应用超时 / 未被观测的路径」也不同层。本篇钉字段语义与错位模式，不写 Hubble UI 操作手册。

本文是「Cilium / eBPF 数据面内核」系列第 8 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 7 篇 · 策略编译	policy map 与 deny 窗口
第 8 篇 · Hubble 信号	flow 字段；metrics vs flows
第 9 篇 · 透明加密	加密路径税
第 12 篇 · 可观测口径	status / metrics 运维

版本锚定：Cilium v1.20.0；Hubble 随该发行嵌入。字段以 Hubble flow API / CLI 文档与 docs.cilium.io/en/v1.20/observability/ 为准。无集群不粘贴伪造 hubble observe 输出。

一、信号分层：先分清「谁在说话」

Hubble 消费 Cilium 数据面导出的可观测事件（monitor / event 管线），经节点 Hubble、可选 Hubble Relay 聚合到集群视图。flow 擅长归因；metrics 擅长告警与容量。用 metrics 回答「哪条 CNP 拒了这个五元组」会不够；用 flow 洪水回答「过去 24h 丢包趋势」会贵。

flowchart TB
  dp["Datapath verdict\npolicy / CT / LB / drop"] --> ev["Monitor / Hubble events"]
  ev --> flow["Flow stream\nCLI / Relay / UI"]
  ev --> hm["Hubble metrics\naggregation"]
  agent["Agent / map / API"] --> cm["Cilium metrics"]
  flow --> page["On-call attribution"]
  hm --> dash["Dashboards / alerts"]
  cm --> dash

二、Flow 关键字段语义（排障坐标系）

下列字段是归因时最常误读的集合（名称以 Hubble flow schema / CLI 列为准；展示名可能略有差异）：

Identity 列的价值：flow 直接给出数字 Identity 与标签翻译，避免「先反查 IP 再猜策略」。这与第 2、7 篇一致：策略键是 Identity，观测也应先对齐 Identity。

Verdict 分层：

• FORWARDED：该观测点允许继续；不保证对端应用已读完、不保证跨节点后半程成功。
• DROPPED：在 Cilium 数据面（或相关路径）主动丢弃；必须读 drop reason。
• REDIRECTED：常指向代理（L7）；最终成败在 Envoy/应用。
• Audit 模式：记录本应拒绝但仍放行的流量——用于演练，不能当成「生产已强制」。

三、Metrics 与 Flows：口径差在哪

3.1 Hubble metrics 示例口径（v1.20 文档）

官方 Observability Metrics 章列出可启用的 Hubble metrics（Helm hubble.metrics.enabled），例如：

注意：flows_processed_total 计的是「被 Hubble 处理的 flow 事件」，不是网卡 pps，也不是应用成功请求数。 开启哪些 metrics、带哪些 labelsContext，直接改变基数与基数爆炸风险。

3.2 何时 metrics 绿、业务仍红

这就是系列关键问题 4 的答案骨架：全绿的 metrics 只说明「你选的聚合序列没报警」，不证明「数据面每一跳都成功」。

四、从告警到 flow 的推荐顺序

1. 定平面：集群内东西向、NodePort 南北向、还是跨集群（ClusterMesh）？
2. 看 Cilium 健康：agent ready、KPR/加密/策略是否在预期模式（cilium status 语义）。
3. 看聚合 drop reason：若已启用 Hubble drop，先按 reason 排序；Policy denied 与 Stale/No mapping 一类原因指向不同篇。
4. 拉 flow：按 namespace、verdict、identity 过滤，对齐第 7 篇的策略窗口假设。
5. 若 flow 为 FORWARDED：下钻节点网卡、对端应用、Service 后端、加密（第 9 篇）。

命令语义（需 Relay 或本地 Hubble）：

# 语义：观察某命名空间丢弃流（不要把示例输出写进正文当实测）
hubble observe --namespace <ns> --verdict DROPPED
# 语义：按 identity / pod 过滤（字段以本机 hubble help 为准）
# hubble observe --from-pod <ns>/<pod> --to-pod <ns>/<pod>

加密流量的可见性受「是否在加密前后观测」影响；官方 Hubble CLI 有 encrypted traffic 过滤相关说明——排障时要声明观测点相对 WireGuard/IPsec 的位置，否则会把密文隧道误当成业务五元组。

五、与策略、Service、加密的字段对齐

不要用「Hubble 没有 DROP」反证「没有 NetworkPolicy 问题」——也可能是流量没走到强制点，或 verdict 在 L7。

六、谱系、争论与开放问题

谱系：网络可观测从 tcpdump / NetFlow / IPFIX，到主机 agent 采样，再到 可编程数据面内生事件（随 eBPF 监控点导出）。Hubble 把 Cilium 的 verdict 翻译成可查询 flow 与可聚合 metrics。它不是通用 APM；分布式追踪仍要应用侧上下文。

争论：

1. 全量 flow vs 采样：全量利于事后追责，税高；采样利于常驻，可能丢掉稀有 deny。生产上「默认采样 + 故障时临时全量」是工程折中，不是理论最优。
2. 高基数标签：labelsContext 塞满 pod IP 时，Prometheus 元数据本身可打垮观测栈——观测税变成新的故障面。
3. 「可观测性即安全」营销 vs 排障坐标：flow 能解释 Cilium 路径上的决策，不能替代对应用与云网络的观测。

开放问题：

1. Hubble 采样与真实丢包归因如何对齐到同一 SLO 仪表盘？（研究台账 08–09）
2. 跨 ClusterMesh 的 flow 时钟与 identity 翻译：Relay 联邦后，事件顺序与集群名冲突如何避免误归因？（第 11、12 篇方向）

七、Relay、基数与「看不见的成功路径」

Hubble Relay 把各节点 Hubble 聚成集群（及 ClusterMesh 场景下的更广）查询面。CLI 指向 Relay 时，过滤条件里的集群名、节点名、时间范围都会影响「你以为看到了全集」。节点 Hubble 崩溃或 Relay 落后时，metrics 刮取若仍打在存活实例上，会出现 局部绿、全局盲区——这与数据面是否丢包无关。

高基数是第二类自伤：为每个 source_ip/destination_pod 打开 labelsContext 后，Prometheus 内存与 scrape 时间上升，告警规则开始「为了活下去」被关掉或降采样。结果是：出事那一周偏偏没有可用的 drop 时间序列。工程纪律是默认用 粗标签（namespace、workload、reason），故障窗口再临时加细过滤的 flow 查询，而不是长期全细粒度 metrics。

「看不见的成功路径」同样误导：同节点 sockmap 短路、或未经期望 TC 点的 hostNetwork 流量，可能不产生你习惯过滤的那类 flow。业务成功且 Hubble 空空，不等于观测坏了，可能是路径根本不经该 observation point。反之，flow 里大量 FORWARDED 只说明 Cilium 放行，应用线程若阻塞在锁上，用户仍报「网络不行」。

与第 6、7、9 篇对齐的快速口诀：

• Policy denied 主导 → 先回策略编译与 Identity 窗口；
• 无 deny 但不通 → 先 Service/LB map 与路由，再加密；
• 只有 HTTP 层失败 → 看 L7 redirect，不要只盯 L3 drop 面板。

把这三条写成 runbook，比再加一张「全绿」大盘更有用。

7.1 事件丢失与背压

数据面可以以很高速率产生 monitor 事件；Hubble 导出、Ring buffer、Relay 传输任一环节背压时，都会 丢事件 而未必丢数据包。结果是：业务流量与策略判定仍在发生，但 flow 流出现缺口，metrics 少计。把「Hubble 没看见 DROP」写成「没有 DROP」之前，先确认导出路径是否健康（agent 日志、Relay 延迟、是否启用了过激过滤）。

反之，重放或调试时打开过于宽的 observe 过滤，会让笔记本与 API 都被事件淹没，造成「观测工具拖慢排障」——过滤条件应先收窄到 namespace 与 verdict，再按需放大。

7.2 与 Cilium agent metrics 的分工再钉一次

混用这四行是「全绿仍不通」的最常见认知错误：四套仪表盘各说各话，没有一张告诉你该信谁。

时间对齐也很关键：Grafana 默认「现在」与 Hubble CLI 默认「此刻流」若差几分钟时钟或时区，会出现「指标尖刺对不上 flow」的假矛盾。排障记录应写下观测时间戳、时区、以及用的是节点本地 Hubble 还是 Relay，方便事后复盘。

加密开启后，还可对照第 9 篇：若只在隧道外层看到 UDP/ESP，不要用业务端口去过滤 flow——先确认解密后观测是否可用，再下策略结论。

最后，Hubble UI 适合演示服务依赖图，不适合当唯一告警源：UI 聚合与过滤默认值可能隐藏低频 deny。值班应以 CLI/metrics 为证据链，UI 只作辅助可视化——这也是本系列不写点击教程的原因。有集群时再贴真实 hubble observe 片段；无集群时只保留命令语义，避免用臆造输出训练错误肌肉记忆。这是证据纪律，不是篇幅技巧。

八、本篇边界

不写：Hubble UI 点击路径、Grafana 仪表盘 JSON、伪造 flamegraph。
完整运维口径（哪些官方指标进值班盘）见第 12 篇；把 drop、identity 漂移、Service 黑洞收成决策树见第 13 篇。

一句话收束：flow 回答「这一次为何如此」；metrics 回答「这一类是否变多」；二者全绿仍可能丢在未计量平面——先定观测点，再读 verdict，最后才骂应用。 下一篇转入加密路径税，观测坐标系到此收束。

参考资料

官方文档（A）

• Cilium v1.20 — Hubble Overview
• Cilium v1.20 — Hubble CLI — 过滤、加密流量、reply
• Cilium v1.20 — Monitoring & Metrics — Hubble metrics 名与标签

源码 / API（A）

• Hubble flow protobuf / API（随 Cilium/Hubble 发行；字段以 v1.20 匹配的版本为准）
• cilium/cilium v1.20.0 monitor / hubble 导出相关包

站内

• 第 7 篇 · 策略编译
• 第 12 篇 · 可观测口径
• 第 13 篇 · 排障坐标系
• k8s-network/13 · Hubble 产品节

→ 上一篇：策略编译 · 系列目录 · 下一篇：透明加密