网络可观测性

• eBPF 在内核无侵入采集
• Hubble 采集服务拓扑、L3/L4/L7 指标、DNS 事件
• 与 Cilium/Cilium agent 集成

Cilium 基于 eBPF 在内核数据面采集流量，Hubble 是其可观测层，无侵入地采集网络数据。它采集：服务拓扑（服务间调用关系）、L3/L4 指标（流量、包、连接）、L7 指标（HTTP/gRPC 请求、延迟、错误）、DNS 事件（解析请求/响应）。实现：Cilium agent 加载 eBPF 程序到内核，采集数据写入 Prometheus 指标与 Hubble 事件流，Hubble UI 可视化拓扑。无需修改应用（无侵入），因为 eBPF 在内核层观察。它提供服务拓扑、L3/L4/L7 指标与 DNS 可观测，用于服务网格/网络排障。

Hubble 的价值是"eBPF 内核采集 + 无侵入 + 拓扑/L7/DNS 可观测"。它把内核数据面变成可观测数据。

• NetFlow/IPFIX 会话级流记录，sFlow 采样统计
• 采样与存储成本
• 流数据 vs 全量抓包

流数据体系用于网络流量观测：NetFlow（Cisco）与 IPFIX（标准版）记录"流"（相同五元组的会话），包含源/目的、端口、字节、时长，汇聚后分析；sFlow 用采样（如 1/1000）统计流量，开销低但粒度粗。采集原理：设备导出流记录到采集器，存储到流数据库。成本：流记录数量大、存储与索引成本高，采样降低存储。与全量抓包取舍：全量抓包（tcpdump/pcap）粒度最细（可看内容），但存储与性能成本极高，只用于短时深挖；流数据成本低、可长期，但只有聚合信息（无内容）。取舍：长期观测用流数据，排障深挖用抓包。

流数据是"聚合流记录，低成本可长期"，抓包是"全量内容，高成本短时"。采样平衡精度与成本。

• 设备层：SNMP/流数据（网络设备）
• 主机层：ss/tcpdump/eBPF（主机）
• 应用层：APM/RUM（应用）

网络可观测性分三层：① 设备层——SNMP（设备指标）、流数据（NetFlow/sFlow）看链路/设备/流量；② 主机层——ss（连接状态）、tcpdump（抓包）、eBPF（内核观测）看主机网络栈与连接；③ 应用层——APM（应用性能、分布式追踪）、RUM（真实用户）看端到端体验。协同建设：设备层看"链路与设备"，主机层看"主机与连接"，应用层看"应用与体验"。排障时跨层对齐：应用慢 → 应用层看耗时 → 主机层看连接/重传 → 设备层看链路/丢包。建立统一指标（延迟、丢包、连接）、统一时间轴，跨层关联。

分层核心是"设备/主机/应用三层各自观测，跨层对齐"。设备看链路、主机看连接、应用看体验，协同定位。

• 主动探测 vs 被动观测数据口径差异
• ICMP 优先级偏差（ICMP 被低/高优先级处理）
• 用业务流量校准

主动探测（ping/mtr/拨测）用 ICMP 或合成流量，数值反映"探测路径"，但 ICMP 可能被设备低优先级处理（丢包率虚高）或高优先级（延迟虚低），不能完全代表真实业务流量。被动观测（TCP 重传、RTT、应用耗时）反映真实业务流量，但只在有流量时才有数据。口径差异：主动是"探测样本"，被动是"真实流量"。校准：用业务流量（被动指标）校准主动探测——比较主动探测的延迟/丢包与被动 TCP RTT/重传，分析 ICMP 偏差，调整阈值。例如 ICMP 丢包高但 TCP 正常，说明 ICMP 被降优先级，主动探测需修正。

口径差异是"主动样本 vs 被动真实"。ICMP 优先级偏差使主动探测失真，需用被动业务流量校准。

• 解析耗时、失败率、上游超时指标
• 缓存命中率
• 监控与告警

DNS 可观测性监控：① 解析耗时（query time）——解析器响应时间，异常高说明上游慢；② 失败率（NXDOMAIN/SERVFAIL/REFUSED 比例）——失败率上升预警故障；③ 上游超时——递归解析器到上游的查询超时，反映上游/链路问题；④ 缓存命中率——缓存命中高则并发好、上游压力小。采集：CoreDNS/unbound 的 metrics（coredns_dns_request_duration、coredns_dns_responses_total），Prometheus 接入。定位解析故障：先看失败率与耗时，再按响应码（NXDOMAIN/SERVFAIL）定位，看上游超时是否与链路/上游宕机相关，缓存命中率低说明需预热或上游慢。

DNS 可观测核心是"耗时 + 失败率 + 上游超时 + 缓存命中率"。按响应码与上游超时定位故障层级。

• 重传率、乱序、duplicate ACK 指标
• 采集方式（netstat/ebpf/抓包）
• 关联链路丢包与队列问题

TCP 丢包与重传观测：重传率（重传包/总包）、乱序（out-of-order）、duplicate ACK（重复 ACK）反映丢包与质量问题。采集：netstat -s（重传/乱序计数）、ss -i（重传/RTT）、eBPF（逐连接）、抓包分析。关联：重传率高多为丢包（链路拥塞/队列溢出/物理丢包），乱序多可能与多路径/路由抖动有关，duplicate ACK 是快速重传触发信号。定位：重传 + 丢包指标高，查链路（SNMP 丢包计数）、队列（qdisc 深度、bufferbloat）、物理层（光模块错误）。用被动指标（真实流量）关联到链路层与队列层。

重传/乱序/dup ACK 是丢包信号。重传高查链路丢包，乱序查路径，dup ACK 触发快速重传，关联到队列与链路。

• VPC 流日志、云 LB/NAT/防火墙日志
• 与自建监控聚合
• 数据格式与摄入

云网络可观测利用云厂商日志：VPC 流日志（记录 VPC 内流量的五元组、字节、动作）、云 LB 日志（访问日志、后端健康）、NAT 网关日志（连接/流量）、云防火墙日志（安全策略命中）。统一聚合：把云日志导出到日志平台（S3 + 开源/云日志服务），或云监控的指标拉到自建 Prometheus，统一格式后聚合分析。方案：用云日志服务采集 → 转存到集中存储 → 自建或云数据分析。指标统一接入 Prometheus/Grafana，日志统一接入 ELK。聚合后能跨"云资源"与"自建应用"关联排障。

云网络观测核心是"云日志导出 + 指标统一采集 + 统一分析"。VPC 流日志/LB/NAT/防火墙日志接入集中平台。

• sidecar 指标（Envoy 遥测）
• 访问日志（sidecar 访问日志）
• Hubble/Flow 网络数据

服务网格与网络可观测协同：sidecar（Envoy）生成应用层指标（请求量、延迟、错误率）与访问日志（请求/响应/上游），反映应用到应用的调用；Hubble/Flow（eBPF 网络数据）反映网络层（连通、丢包、连接）。排障时对齐：应用慢先看 sidecar 指标（延迟、错误率）定位服务，再看 sidecar 访问日志（上游状态、耗时），看 Hubble/Flow 的网络层（丢包、重传、连接）。用公共标识（服务名、命名空间、IP）把 sidecar 指标与网络数据关联，区别"应用慢"与"网络慢"。两者互补：sidecar 看应用层，Hubble 看网络层。

协同是"sidecar 看应用层 + Hubble 看网络层，用服务名/IP 对齐"。区分应用慢与网络慢。

• 延迟分解：客户端→边缘→源站各段
• RUM 看客户端到边缘
• 拨测看边缘/源站

网络延迟分解用工具链逐段定位：① RUM——采集真实用户端到端（客户端到服务的总耗时），分 DNS/TCP/TLS/TTFB/下载；② 拨测——从探测点测边缘与源站，量化边缘到源站、边缘到客户端的延迟；③ tcpdump/抓包——在边缘/源站抓包，看各段 RTT、握手、重传。定位顺序：RUM 看总体与前端，拨测看网络分段，抓包看具体连接。区分"客户端到边缘"（RUM/拨测）与"边缘到源站"（内部回源/抓包）。用各段耗时对比找出瓶颈段（如边缘回源慢、源站处理慢）。

延迟分解是"RUM 看端到端 + 拨测看分段 + 抓包看连接"。逐段对比定位瓶颈段。

• 基线检测流量突增/突降
• 重传率、丢包率告警
• 阈值与基线

网络异常检测设计：① 基线检测——用历史数据建立流量/指标基线（如按小时/天周期），检测突增/突降（如偏离基线 3σ 或百分比），发现流量异常（突增可能攻击/热点，突降可能故障）；② 异常重传率——重传率超过阈值（如 1%）告警，反映丢包/拥塞；③ 丢包率告警——ICMP/业务丢包率超阈值告警。告警设计：动态基线 + 固定阈值结合，多级告警（warning/critical），告警去噪（连续 N 次才告警）、关联（重传率+丢包率同时高更严重）。用 Prometheus 的 anomaly 检测（如 predict_linear）或 Z-score 做基线。

异常检测核心是"基线 + 阈值 + 去噪 + 关联"。流量突增/突降用基线，重传/丢包用阈值，多指标关联。

• 基数问题：按 Pod/IP/五元组导致高基数
• 基数控制：降维、聚合、标签限制
• 采样降低数据量

网络指标基数治理：按 Pod/IP/五元组聚合会生成高基数时间序列（每个 IP/流一个序列），导致存储爆炸与查询慢。治理：① 降维——合并不必要的标签，按服务/命名空间聚合而非每个 IP；② 采样——对高基数数据采样（如 gRPC/流数据按比例采样），降低量；③ 预聚合层——先用 recording rules 或流式预聚合把细粒度数据聚合成粗粒度（按服务、按接口），再存时序库，减少基数。设计：高基数数据（逐 IP/流）用采样 + 预聚合，低基数（按服务）全量。用 Prometheus recording rules 或 Thanos/流式预聚合。

基数治理核心是"降维 + 采样 + 预聚合"。高基数（逐 IP/流）需采样与预聚合，低基数按服务全量。

• mtr/traceroute 路径探测
• 路径变化与延迟抖动
• BGP 路由变化影响

路径可视化用 mtr（结合 traceroute 与 ping，连续测每跳丢包/延迟）与 traceroute 探测路径。分析延迟抖动：若某跳延迟/丢包波动，说明该段链路/队列问题；路径变化（跳数/节点变化）会导致延迟突变。BGP 路由变化影响：路由变化（前缀切换、路径改道）可导致流量走不同路径，延迟/丢包变化。方法：用 mtr 持续观察路径与每跳延迟，对比 BGP 路由变更时间（bgpmon/流数据），若 BGP 变化与延迟抖动时间吻合，说明路由变化导致。用多路径对比（主动/被动）分析抖动来源。

路径可视化是"mtr 看每跳 + BGP 路由变化关联"。路径或路由变化导致延迟抖动，需时间对齐。

• conntrack 表使用率
• 连接状态分布
• 连接建立失败率

连接级可观测：① conntrack 表使用率——/proc/sys/net/netfilter/nf_conntrack_count 与 nf_conntrack_max 之比，使用率高接近满时新连接被丢弃，需告警；② 连接状态分布——ESTABLISHED/TIME_WAIT/SYN_RECV/CLOSE_WAIT 数量，异常（如 CLOSE_WAIT 堆积）预警；③ 连接建立失败率——SYN 无响应/拒绝/超时比例，反映建连失败。采集：conntrack -L//proc/net/nf_conntrack、ss -tan 状态统计、核心指标（node_nf_conntrack_entries）。告警：conntrack 使用率 >80% 告警、连接状态异常、建立失败率阈值。连接级观测用于发现"连接耗尽、泄漏、建连失败"故障。

连接级观测核心是"conntrack 使用率 + 状态分布 + 建连失败率"。conntrack 满、连接泄漏、建连失败是主要告警。

• qdisc 队列深度观测
• bufferbloat 现象（缓冲过大致延迟高）
• AQM（主动队列管理）与 BBR 调优

网络队列与缓冲观测：qdisc 队列深度（tc -s qdisc show）反映队列积压，深度高说明拥塞/缓冲堆积。bufferbloat 是"缓冲过大导致延迟高"——队列大量积压时 RTT 飙升，即使吞吐稳定。调优：AQM（主动队列管理，如 CoDel/fq_codel）主动丢弃/标记，控制队列深度，降低延迟；BBR 拥塞控制基于 RTT 探测，减少缓冲堆积。联动：观测 qdisc 深度与 RTT 抖动发现 bufferbloat，用 fq_codel/CoDel 做 AQM 降延迟，用 BBR 优化高带宽长延迟链路。观测指标（队列深度、RTT、重传）驱动 AQM/BBR 调优。

bufferbloat 是"缓冲过大延迟高"。观测深队列 + 高 RTT，用 AQM（fq_codel）与 BBR 调优。

• 分布式追踪 span 时延
• 网络 RTT/丢包指标
• 交叉关联

关联网络指标与分布式追踪定位慢请求：分布式追踪（Jaeger/Zipkin）记录跨节点 span 时延（服务间调用耗时），网络指标（RTT、丢包、重传）记录链路质量。方法：① 追踪看"慢在哪个 span"（哪个服务间调用慢）；② 用该 span 对应的时间段与网络指标（RTT/丢包）关联，若该时间段网络丢包/RTT 高，说明网络慢；若网络正常，说明应用慢。用公共标识（trace ID、服务名、IP、时间窗）关联。若跨节点 span 时延高但网络 RTT 正常，是应用层；若 RTT 高，是网络层。交叉定位避免误判。

关联核心是"追踪慢在哪个 span + 网络 RTT/丢包是否同步高"。用时间窗与 trace 关联区分应用慢与网络慢。

• 压测流量识别（标记、隔离）
• 带宽/连接数/延迟实时观测
• 瓶颈定位

全链路压测中的网络观测：① 压测流量识别——用标记（header/端口/独立压测环境）隔离压测流量，避免与真实流量混淆；② 实时观测——压测时观测带宽（吞吐）、连接数（并发）、延迟（RTT/响应时间）、丢包/重传，用 Grafana 实时大盘；③ 瓶颈定位——压测加负载时看瓶颈在哪段：带宽打满（网络瓶颈）、连接数超限（LB/连接池）、延迟升（应用/队列）、丢包（链路）。用指标逐步加压，定位网络/应用瓶颈。压测到瓶颈后反推容量。压测流量识别用专门环境/标记，观测用实时指标。

压测网络观测核心是"识别压测流量 + 实时观测带宽/连接/延迟 + 定位瓶颈段"。加压观测定位瓶颈。

• 采集 Agent（exporter/Telegraf）
• 时序存储（Prometheus/TSDB）
• 流数据检索（Elasticsearch/ClickHouse）

网络可观测平台架构：① 采集 Agent——node_exporter、Telegraf、eBPF Agent 采集指标与流数据，抓包/流数据采集；② 时序存储——Prometheus（指标）或 TSDB（VictoriaMetrics/Thanos）存时序指标；③ 流数据检索——NetFlow/sFlow 流数据存 Elasticsearch/ClickHouse 做检索分析；④ 告警链路——Prometheus Alertmanager 告警，接通知。架构：Agent 采集 → 时序库存指标 + 分布式库存流数据 → 告警引擎 + 可视化（Grafana）。选型考量：指标量级、流数据量、检索需求、告警时效。设计要分层：采集、存储、检索、告警、可视化。

平台架构是"采集 Agent + 时序存储（指标）+ 流数据检索（流）+ 告警链路"。选型看指标量、流数据量与检索需求。

• INT 带内遥测（内嵌采集每跳延迟）
• gNMI 流式遥测（订阅设备数据）
• 落地现状与挑战

网络遥测新技术：① INT（In-band Network Telemetry）——在数据包内嵌采集元数据（每跳延迟、队列、缓存），逐跳采集网络路径状态，粒度极细，但需硬件支持、开销与标准化问题，落地受限；② gNMI（gRPC Network Management Interface）——流式遥测，设备订阅推送指标（订阅模式），相比 SNMP 轮询实时性高、效率高，广泛落地。落地现状：gNMI 已是主流（云厂商/交换机支持），INT 受硬件与标准化限制，部分数据中心试点。与 SNMP 对比：SNMP 轮询慢、粒度粗，gNMI 流式订阅实时高效，INT 逐跳更细但成本高。

遥测现状是"gNMI 流式订阅主流、INT 逐跳细粒度受硬件限制"。gNMI 替代 SNMP 轮询，INT 是更细的探索。

• 交换机端口流量与丢包计数
• 光模块光功率与误码
• 对应用延迟的影响

链路层观测：交换机端口流量与丢包计数（show interface 的 input/output errors、CRC、runts、discards）反映物理层/链路问题；光模块参数（光功率 RX/TX、误码率、温度）反映光链路质量。影响：端口丢包（CRC/误码）导致重传，重传增加延迟；光功率低/误码高导致链路不稳定、丢包、抖动，直接拉高应用延迟。观测：SNMP 采集端口计数与光模块参数，阈值告警（光功率低于阈值、误码率上升）。链路层问题（物理/光）会表现为应用丢包与延迟抖动，需在链路层观测发现。

链路层观测是"端口丢包计数 + 光模块光功率/误码"。物理层/光问题导致丢包重传，拉高应用延迟。