企业出海多云网络可观测性架构实战：VPC Flow Logs + 流量镜像 + 跨云网络性能监控（2026最新版）

📅 2026-10-06 · ChengziCloud - 一站式云端服务

Meta Description: 出海企业多云网络可观测性完整指南：为什么应用监控救不了网络问题、采集层流日志与流量镜像怎么选、路径分析与流量分析的工程化落地、AWS/阿里云/腾讯云三朵云能力与计费口径对比、真实单价与派生测算、90天落地路线，一篇讲透。

> 关键词： 网络可观测性、多云网络监控、VPC Flow Logs、流量镜像、网络性能监控 NPM、跨云网络诊断

前言：先给结论

如果你的团队已经上了 Prometheus + Grafana + 链路追踪，服务侧的指标全绿，却仍然会被"偶发超时""跨云调用抖动""某条路径突然丢包"折磨，那么你缺的不是又一个仪表盘，而是网络层的可观测性。

本文给三条可以直接落地的结论，后面所有章节都在论证它们：

1. 应用可观测与网络可观测是两套数据面，不可互相替代。 前者回答"哪个服务出错了"，后者回答"这条路径为什么不稳"。一个 P99 从 120ms 涨到 800ms 的请求，在应用侧只是一根变高的曲线，在网络侧才能定位到是跨可用区跳数增加、还是某条隧道的 MTU 触发分片。 2. 网络可观测的成本几乎全部在"采集量与目的地"，不在"功能开关"。 同一个流日志功能，投递到对象存储和投递到日志服务，账单可以差一个数量级；采样率从 100% 降到 10%，账单同比例下降而对定位问题几乎没有损失。 3. 三朵云没有统一的网络可观测产品，必须自建"统一分析面"。 AWS 有 Reachability Analyzer + Traffic Mirroring + Network Access Analyzer，阿里云有网络智能服务 NIS 把路径分析与流量分析打包成一个产品，腾讯云国际站则连 NIS 都不提供，只能用 VPC 流日志 + 自建分析。指望一家厂商的统一控制台看三朵云，是选型阶段最常见的幻觉。

> 边界说明：本文只讲网络数据面的可见性——流量从哪里来、走到哪里、在哪里丢、为什么慢。它不替代应用可观测（指标/日志/链路）、安全运营（威胁检测响应）、出网架构（NAT 与私网访问设计）和负载均衡选型，四者的分工见第一节边界表。

一、为什么"应用可观测"救不了"网络问题"

先看三个出海企业最常见的真实症状，它们有一个共同点：在应用监控里都"看起来正常"。

- 症状 A：接口偶发超时，服务指标全绿。 网关报 504，但下游服务的 CPU、内存、GC、QPS 全部正常，错误率也没有抬升。真相往往在网络上：连接建立阶段 SYN 重传、或者跨可用区的连接被某台 NAT 网关的连接数上限丢弃——这些事件不产生应用日志。 - 症状 B：跨云调用 1% 的抖动。 主力业务在法兰克福，灾备在新加坡，两地之间的 RPC 有 1% 的请求延迟翻倍。平均延迟看着没问题，因为这 1% 被平均值稀释了。要抓住它，你必须能按"源 IP × 目的 IP × 目的端口 × 地域"下钻流量。 - 症状 C：突发的黑障但没有告警。 某个子网的出方向流量在凌晨 3 点掉了一半，没有任何一个应用告警——因为受影响的是一批离线任务。这类问题只有流量视角才能发现。

1.1 三层可观测的分工边界

把"可观测"按数据面拆成三层，你会立刻看清自己缺的是哪一层：

| 层次 | 回答的问题 | 主要数据源 | 典型工具 | 站内对应文章 | |---|---|---|---|---| | 应用层 | 哪个服务/接口出错了 | 指标、日志、Trace | Prometheus、ELK、OTel | 多云可观测性与告警治理（08-16） | | 网络层 | 这条路径为什么慢/丢/不通 | 流日志、流量镜像、路径分析 | Flow Logs、NIS、NPM | 本文 | | 安全层 | 有没有人在做坏事 | 审计日志、威胁检测 | CloudTrail、SOC/SIEM | 多云安全运营中心（09-17） |

1.2 与站内既有文章的边界

本文与以下文章不重复，请对照阅读：

- 多云可观测性与告警治理（08-16）：管的是应用三支柱（指标/日志/链路）与 SLO 告警出口，本文从"网络数据面"这一层切入。 - 多云统一出网与私网访问（09-22）：管的是出网链路怎么设计、怎么省钱、怎么被审计；本文管的是"这条链路跑起来之后怎么看"。 - 多云网络互通与 Transit（09-04）：管的是三朵云之间怎么打通（传输层）；本文管的是打通之后的流量画像。 - 多云负载均衡选型（09-26）：管的是入站流量分给谁；本文管的是流量分出去之后的行为。 - 多云安全运营中心（09-17）：管的是安全事件的检测与响应；本文的网络数据是它的一个数据源，但目标函数不同（性能 vs 安全）。 - AWS 单云生产运维（07-08）：覆盖了单云 AWS 的 VPC Flow Logs 排障与 Reachability Analyzer，本文是三朵云的对比与工程化。

二、网络可观测性的五层模型

网络可观测不是"开个流日志"这么简单，它是一条从采集到告警的流水线。任何一层缺失，整条链路都跑不通。

`mermaid graph TD A["L1 采集层: VPC Flow Logs / 流量镜像 / eBPF"] --> B["L2 传输汇聚层: 就近落地 + 归一化"] B --> C["L3 存储分析层: 流量分析 / 路径分析 / 查询引擎"] C --> D["L4 可视化层: 网络拓扑 / 流量地图"] C --> E["L5 告警与行动层: 阈值告警 / 自动工单"] D --> E E --> F["回流: 拓扑与流量作为诊断输入"] F --> C `

对应的物理全景图（跨三个地域的业务 VPC）：

`text ┌──────────────────────────── 统一分析面（自建） ────────────────────────────┐ │ OpenSearch / ClickHouse ← 归一化事件 ← 汇聚器（就近采集、跨云只传聚合） │ └───────────────▲───────────────────────────────────────▲────────────────────┘ │ │ ┌───────────────┴───────────────┐ ┌────────────────┴──────────────────┐ │ 法兰克福 VPC（阿里云） │ │ 新加坡 VPC（AWS） │ │ ├─ 流日志 → SLS / OSS │ │ ├─ Flow Logs → S3 / CloudWatch │ │ ├─ NIS 路径分析（控制面） │ │ ├─ Traffic Mirroring → 分析实例 │ │ └─ NIS 流量分析（商业版） │ │ └─ Reachability Analyzer │ └───────────────▲───────────────┘ └────────────────▲──────────────────┘ │ │ └──────────── 跨云专线 / CEN·TGW（数据面）───────────────┘ `

三条铁律：

1. 原始流量数据不跨境，只汇聚归一化事件。 这是合规底线，也是成本底线——把原始流日志跨地域传输，既踩数据出境，又让流量费超过存储费。 2. 采集层就近落地，分析层集中收敛。 采集器部署在每朵云、每个地域内部，把字段归一化后再送统一分析面。 3. 控制面工具与数据面工具分开选。 路径分析这类"按需调用"的控制面能力（如 AWS Reachability Analyzer、阿里云 NIS 路径分析）按次计费，可以只用一家云的；而数据面的流日志必须三朵云全开，否则你的分析面永远缺一块。

三、采集层：流日志、流量镜像、eBPF 三选一

采集层是整个体系的地基。三种主流手段不是"哪个更好"，而是"看你要看什么"。

| 维度 | VPC Flow Logs（流日志） | Traffic Mirroring（流量镜像） | eBPF（主机侧采集） | |---|---|---|---| | 采集粒度 | 连接级（五元组 + 字节数 + 动作） | 包级（完整载荷） | 进程/连接级 + 内核事件 | | 载荷内容 | 无（只有元数据） | 有（可深度解析协议） | 部分（依赖运行时） | | 部署位置 | 云平台侧，VPC/子网/ENI 维度 | 云平台侧，ENI 维度 | 主机/容器内 | | 性能开销 | 极低（平台侧） | 中（复制流量到分析目标） | 中低（可限流采样） | | 典型用途 | 流量画像、安全审计、成本分摊 | 协议级排障、入侵取证 | 应用-网络关联、延迟归因 | | 跨云一致性 | 好（三云都有） | 差（各家字段与目标不同） | 好（同一套 eBPF 程序可复用） | | 计费口径 | 按目的地计费（投递量/存储） | 按 ENI·会话小时计费 | 自建（机器成本） | | 最适合的场景 | 长期开启、全量铺底 | 短周期、定点深挖 | 疑难杂症定位 |

三条选型结论：

1. 流日志必须长期全量铺底，这是唯一"三朵云都有、且便宜到可以一直开着"的采集方式。 它是你的"网络账本"，绝大部分问题在连接级就能定位。 2. 流量镜像只在"流日志看不到"的时候开。 需要看 TLS 握手失败、需要抓 DNS 查询、需要协议级取证时才用，用完删会话——它的计费与"会话是否存活"绑定，而不是与"是否真的在传数据"绑定。 3. eBPF 是"最后一公里"的补充，不是替代。 它最大的价值是把"哪个进程发起了这条连接"这个问题回答掉，从而把网络事件和应用事件对齐。

3.1 流日志的字段与采样

一个工程上必须提前决定的问题是采样率。流日志的默认采样率通常是全量（1:1），但高流量场景下可以降到 1/N：

- 100% 采样：适合单条流日志量可控的业务 VPC（如每月几十 GB）。 - 1:10 采样：适合高吞吐场景，用于"趋势与画像"，不适合"逐条取证"。 - 混合策略：核心生产 VPC 全量、非核心 VPC 采样、所有 VPC 的出方向全量。

需要特别记住的是：流日志记录的是"连接结束后聚合或按窗口聚合"的记录，不是实时包流。 短连接（如大量 HTTP/1.1 短请求）会产生海量记录，而长连接（如数据库、消息队列）只会产生很少的记录但字节数巨大——这一点直接决定你的账单结构，第七节会算给你看。

四、分析与诊断层：从"看到"到"定位"

采集只是把数据拿回来，分析层才产生判断。这一层有四个核心能力。

4.1 路径分析（连通性诊断）

当你面对的是"不通"而不是"慢"，路径分析是最快的手段。它的原理是：给定源与目的，沿着路由表、安全组、网络 ACL、NAT、负载均衡、端点策略逐跳模拟转发，指出在哪一跳被阻断以及原因。

- AWS 侧叫 Reachability Analyzer，按"每次分析"计费。 - 阿里云侧由 NIS（网络智能服务）的路径分析覆盖，官方描述为"端到端分析网络连通性，诊断网络配置错误引起的连接问题。当目的地不可到达时，识别阻塞位置和原因"。 - 腾讯云国际站没有对应的独立产品（其 NIS 产品页在国际站返回 404），只能靠流日志 + 自建规则+人工推断。

4.2 流量分析（性能与画像）

流量分析回答"网络中现在发生什么、过去发生过什么"。阿里云 NIS 的流量分析器（商业版）把这件事产品化，官方给出的三类用法值得抄：

- 实时流量分析：快速发现当前网络的异常情况，并分析造成异常的原因。 - 历史流量分析：还原并追溯历史流量情况，协助历史异常问题查因。 - 业务流量分析：基于场景分析业务流量，感知业务网络异常，评估网络质量和事件影响面。

在 AWS 与腾讯云上，这一步通常用"流日志 + 查询引擎"自行拼装：AWS 用 Athena / CloudWatch Logs Insights，腾讯云用 CLS 日志服务。能力等价，但需要你自己写查询与看板。

4.3 网络拓扑（架构即视图）

网络拓扑把 VPC、子网、路由表、实例、负载均衡、NAT 的关联关系可视化，用于配置验证与统一运维。阿里云 NIS 提供"网络拓扑"与"专有网络拓扑"两级视图；AWS 侧可用 Network Manager / VPC 资源图替代。它的价值在变更窗口最高：一次路由表改动影响哪些实例，拓扑图能一眼看清。

4.4 性能观测（延迟基线）

阿里云 NIS 的性能观测提供"阿里云内及互联网间的网络平均时延数据"，用于地域与可用区选型。对出海企业而言，这类跨地域延迟基线是容量规划与选址决策的输入——把它与本站的容量规划方法接起来，就能回答"把批处理放在哪个地域最划算"。

| 分析能力 | 回答的问题 | AWS | 阿里云 | 腾讯云国际站 | |---|---|---|---|---| | 路径分析 | 为什么不通用哪一跳断的 | Reachability Analyzer | NIS 路径分析 | 无独立产品 | | 流量分析 | 流量构成与异常 | Flow Logs + Athena/CWLI | NIS 流量分析器 | 流日志 + CLS | | 网络拓扑 | 配置关联关系 | Network Manager / 资源图 | NIS 网络拓扑 | 控制台拓扑 | | 性能观测 | 跨地域延迟基线 | CloudWatch 网络指标 | NIS 性能观测 | 云监控 + 自建探测 | | 合规评估 | 我的访问面是否过宽 | Network Access Analyzer | NIS 诊断能力 | 无独立产品 |

五、三朵云网络可观测能力对比

下面这张表是选型时的核心参考。注意"有产品"和"产品好用"是两回事，更要看跨云能不能对齐。

| 能力维度 | AWS | 阿里云 | 腾讯云国际站 | |---|---|---|---| | 流日志 | VPC Flow Logs，支持 VPC/子网/ENI 三级 | VPC 流日志，支持 VPC/交换机/弹性网卡 | VPC 流日志（product 1015） | | 流日志目的地 | CloudWatch Logs / S3 / Firehose | SLS 日志服务 / OSS | CLS 日志服务 / COS | | 流量镜像 | Traffic Mirroring，包级，ENI 维度 | 流量镜像（支持 VPC 内/跨 VPC） | 流量镜像（美东等部分地域） | | 路径分析 | Reachability Analyzer | NIS 路径分析 | 无独立产品 | | 合规可达性评估 | Network Access Analyzer | NIS 诊断能力 | 无独立产品 | | 流量分析产品 | 无独立产品（Flow Logs + Athena/CWLI） | NIS 流量分析器（商业版） | 无独立产品（流日志 + CLS） | | 网络拓扑 | Network Manager | NIS 网络拓扑 | 控制台网络拓扑 | | 跨地域延迟数据 | CloudWatch 网络指标 | NIS 性能观测 | 云监控 + 自建探测 | | 网络加密态势 | VPC Encryption Controls | 由安全组/加密能力覆盖 | 由私有网络策略覆盖 | | 计费口径 | 端口级/ENI 级/分析次 | 按流量分析处理量 | 按流日志存储与投递 | | 免费额度 | 部分分析能力有预览期 | 按量计费 | 按量计费 | | 跨云统一视图 | 无 | 无 | 无 |

三条选型结论：

1. 数据面三朵云都要开流日志，但目的地要能收敛。 如果三朵云的流日志各自躺在 SLS、S3、CLS 里，你等于建了三个互不相通的孤岛。工程上的做法是：各自落在本云的对象存储/日志服务里，再用一个统一的查询面（OpenSearch / ClickHouse）做跨云归一化。 2. 控制面能力可以只用一家。 路径分析、可达性评估这类按需调用的能力，只在主云开启即可——故障排查时，跨云问题往往先由流量画像缩小范围，再回到具体云做路径分析。 3. 腾讯云国际站缺的正是"控制面产品"，所以它最依赖自建。 在腾讯云上，你的路径分析与流量分析基本要靠流日志 + CLS + 自写规则完成，工程量要提前评估。

六、实操：三朵云的采集与分析配置

6.1 AWS：开启流日志 + 流量镜像 + 路径分析

开启一条投递到 CloudWatch Logs 的 VPC 级流日志（注意需要先创建日志组并授予投递权限）：

`bash // 1) 先创建日志组 aws logs create-log-group --log-group-name /net/flowlogs

// 2) 创建 VPC 级流日志，记录全部流量 aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids vpc-0a1b2c3d4e5f6a7b8 \ --traffic-type ALL \ --log-destination-type cloud-watch-logs \ --log-group-name /net/flowlogs \ --deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole `

配置 Traffic Mirroring 做包级深挖。先建镜像目标与分析过滤器，再建会话：

`bash // 镜像目标：把复制流量送到分析实例的 UDP 4789 端口（VXLAN） aws ec2 create-traffic-mirror-target \ --network-interface-id eni-0a1b2c3d4e5f6a7b8 \ --network-load-balancer-port 4789

// 过滤器（先全通过，再按需收紧） aws ec2 create-traffic-mirror-filter --description "capture-all"

// 会话 aws ec2 create-traffic-mirror-session \ --network-interface-id eni-0a1b2c3d4e5f6a7b8 \ --traffic-mirror-target-id tmt-0a1b2c3d4e5f6a7b8 \ --traffic-mirror-filter-id tmf-0a1b2c3d4e5f6a7b8 \ --session-number 1 `

路径分析是一个两步动作——先建"网络洞察路径"，再启动分析：

`bash aws ec2 create-network-insights-path \ --source i-0a1b2c3d4e5f6a7b8 \ --destination i-1a2b3c4d5e6f7a8b9 \ --protocol TCP \ --destination-port 443

aws ec2 start-network-insights-analysis \ --network-insights-path-id nip-0a1b2c3d4e5f6a7b8 `

6.2 阿里云：NIS 控制台 + 流日志

阿里云的路径分析、流量分析、网络拓扑都在 NIS 控制台（nis.console.aliyun.com）里，属于开箱即用的控制面能力。落地时的三步：

1. 在 NIS 控制台完成网络拓扑的首次扫描，确认 VPC、交换机、路由表的关联关系与预期一致。 2. 对"不通"的问题用路径分析：指定源与目的，读取逐跳结果与阻断原因。 3. 对"慢/异常"的问题开启流量分析器（商业版），先看实时流量，再按需回看历史流量。

流日志侧用 Terraform 声明，避免手工点选：

`hcl resource "alicloud_vpc_flow_log" "prod" { flow_log_name = "prod-vpc-flowlog" log_store_name = "flowlog-store" project_name = "flowlog-project" resource_type = "VPC" resource_id = alicloud_vpc.prod.id traffic_type = "All" status = "Active" } `

6.3 腾讯云：流日志 + CLS

腾讯云国际站没有 NIS，采集走 VPC 流日志投递到 CLS。创建流日志时需要指定资源类型与日志集（CLS 的 LogSet/LogTopic），OpenAPI 入口为 VPC 的 CreateFlowLog。落地建议是先把流日志投递到 CLS 的独立 LogTopic，再在 CLS 上做检索与告警，不要把网络日志和业务日志混在同一个 LogTopic，否则检索成本和权限边界都会失控。

6.4 跨云归一化：把三家的字段对齐

跨云分析的第一个坑是字段不同名。以最常见的五元组为例：AWS 用 srcaddr/dstaddr/srcport/dstport/protocol，其它厂商的字段命名与取值格式各不相同（有的用数字协议号、有的用协议名）。工程做法是在采集侧统一重命名，把三家的字段映射到同一套 schema：

`text 统一字段: src_ip, dst_ip, src_port, dst_port, protocol, action, bytes, packets, start_ts, end_ts, region, cloud, vpc_id AWS: srcaddr, dstaddr, srcport, dstport, protocol, action, bytes, packets, start, end 对齐要点: protocol 统一成数字 (TCP=6, UDP=17, ICMP=1) 对齐要点: action 统一成 ALLOW / DENY 两个枚举对齐要点: 时间统一成 epoch 毫秒 `

6.5 一条能立刻用上的查询

在 CloudWatch Logs Insights 里找出"被拒绝最多的前 20 个目的端口"，这是发现安全组配置错误或异常扫描最快的一招：

`sql fields @timestamp, srcAddr, dstAddr, dstPort, action | filter action = "REJECT" | stats count(*) as rejects by dstPort, srcAddr | sort rejects desc | limit 20 `

在 Athena 上对投递到 S3 的流日志做"按小时统计出流量 TOP 10 目的 IP"：

`sql SELECT date_trunc('hour', from_iso8601_timestamp(start)) AS h, dstaddr, sum(bytes) / 1024.0 / 1024.0 / 1024.0 AS gb FROM vpc_flow_logs WHERE start >= '2026-10-01T00:00:00Z' GROUP BY 1, 2 ORDER BY gb DESC LIMIT 10; `

七、成本：网络可观测的账单长什么样

7.1 先看计费口径，再看单价

网络可观测的账单结构和大多数云服务相反：功能开关几乎不花钱，钱花在"数据去了哪里"和"能力按什么单位计费"上。 先记住这张口径表：

| 能力 | 计费口径 | 关键反直觉点 | |---|---|---| | 流日志采集 | 平台侧免费，费用在目的地 | 同一份数据投递到不同目的地，价差可达数倍 | | 流日志投递（日志服务） | 按投递量分档 | 量越大单价越低，小流量反而单价最高 | | 流日志归档 | 按归档存储量 | 归档费远低于投递费，长期留存要靠它 | | 流量镜像 | 按 ENI·会话小时 | 与是否真的在传数据无关，删会话才停计费 | | 路径分析 | 按"每次分析" | 自动化轮询会放大这笔费用 | | 可达性评估 | 按"分析的 ENI 数" | 全量评估比按需评估贵得多 | | 网络加密控制 | 按"非空 VPC·小时" | 与流量、与用量完全无关，是按存量资源计费 |

7.2 AWS 已验证单价（us-east-1 / 定价页示例口径）

| 计费项 | 单价 | 来源口径 | |---|---|---| | 流量镜像会话 | $0.015 / ENI·小时 | 官方定价页示例（俄亥俄） | | 路径分析 Reachability Analyzer | $0.10 / 次分析 | 官方定价页示例 | | 可达性评估 Network Access Analyzer | $0.002 / ENI·次分析 | 官方定价页示例 | | VPC Encryption Controls | $0.15 / 非空 VPC·小时 | 官方定价页示例 | | 流日志投递（日志服务，vended logs） | 0–10 TB $0.50/GB；10–30 TB $0.25/GB；30–50 TB $0.10/GB；50 TB 以上 $0.05/GB | CloudWatch 定价页示例（N. Virginia） | | 日志归档 | $0.03 / GB | CloudWatch 定价页示例 | | Firehose 摄取（如走 Firehose） | $0.029 / GB（首 500 TB/月） | CloudWatch 定价页示例 |

阿里云与腾讯云的对应能力（NIS 流量分析器、VPC 流日志与 CLS 存储）的价格随地域与计费档变化较大，请以官网定价计算器与实时报价为准，本文不代为断言具体单价。

7.3 一个可复现的月度测算

设定场景：一个中等规模出海业务，3 个非空 VPC（生产、预发、共享服务），开流日志并投递到日志服务，每月产生 300 GB 流日志数据，长期归档后压缩到 60 GB；此外为一次排障开了5 个 ENI 的流量镜像（存活一整个月 720 小时），当月跑了 50 次路径分析、2 次全量可达性评估（每次 500 个 ENI），并对 3 个 VPC 开启了加密控制。

| 计费项 | 计算式 | 金额（美元/月） | |---|---|---| | 流日志投递（100% 采样） | 300 GB × $0.50 | 150.00 | | 流日志归档 | 60 GB × $0.03 | 1.80 | | 流量镜像（5 ENI × 720 h） | 5 × 720 × $0.015 | 54.00 | | 路径分析（50 次） | 50 × $0.10 | 5.00 | | 可达性评估（2 次 × 500 ENI） | 2 × 500 × $0.002 | 2.00 | | 网络加密控制（3 个非空 VPC × 720 h） | 3 × 720 × $0.15 | 324.00 | | 合计 | — | 536.80 |

年化约 $6,441.60。

这张表里面最值钱的一行是最后一行：占比 60.4% 的支出既不是日志、也不是镜像，而是"网络加密控制"——它按非空 VPC 的小时数计费，与你的流量规模、与流日志量毫无关系。很多团队在预算阶段只算了"流日志要多少钱"，上线后被这笔按存量资源计费的开销打懵。

7.4 采样率是唯一的大杠杆

把同一个场景的采样率从 100% 降到 10%（流日志投递量从 300 GB 降到 30 GB）：

| 方案 | 投递量 | 投递费 | 相对 100% 采样 | |---|---|---|---| | 100% 采样 | 300 GB | $150.00 | 基准 | | 10% 采样 | 30 GB | $15.00 | 降 90% |

降幅 90%，而对"趋势、画像、异常发现"这三类用途几乎没有损失。 只有"逐条取证"才需要全量——而逐条取证可以用流量镜像短周期定点解决，不需要长期全量流日志。

7.5 三个最容易漏算的账户

1. 流量镜像的"僵尸会话"。 官方明说：网络接口已解绑、实例已停止或已终止、甚至实例类型已变更为不支持的机型，只要你没有删除镜像会话，就继续计费。排障结束后第一件事就是删会话。 2. 日志本身也是跨地域流量。 如果你把丙地域的流日志投递到甲地域的日志服务，中间产生的是跨地域数据传输费，而这笔钱往往比日志存储费还贵。正确姿势是日志就近落地。 3. 查询成本。 在日志服务上做全表扫描式查询、或者在 Athena 上对未分区的 S3 流日志做大范围扫描，扫描量都会单独计费。分区与保留策略必须在第一天就设计好。

八、90 天落地路线

| 阶段 | 时间 | 目标 | 交付物 | 验收标准 | |---|---|---|---|---| | 第一阶段：铺底 | 第 1–3 周 | 三朵云都开流日志 | 采集清单 + 目的地规划 | 三朵云均有连续 7 天流日志 | | 第二阶段：归一 | 第 4–7 周 | 字段对齐 + 统一查询面 | 归一化 schema + 查询引擎 | 一条 SQL 能跨云按 IP 下钻 | | 第三阶段：诊断 | 第 8–11 周 | 接入路径分析与拓扑 | 排障手册 + 值班流程 | 15 分钟内定位一次人为断链 | | 第四阶段：告警 | 第 12–13 周 | 从"能看"到"能报" | 3–5 条高价值网络告警 | 告警可行动、无噪音 |

分阶段的三条提醒：

- 不要一开始就追求全量采集。 先 100% 采样跑两周摸清量级，再决定采样率，比反过来省钱得多。 - 路径分析优先接"变更流程"而不是"告警流程"。 每次路由表、安全组、NAT 变更后自动跑一次路径分析，比在告警风暴里跑分析更有价值。 - 告警要少而准。 网络告警最容易失控，起步只做 5 条以内，例如"某子网出方向流量环比下降 50%""某目的端口的 REJECT 突增 10 倍"，每条都必须能指向一个具体动作。

常见问题 FAQ

Q1: 团队已经上了链路追踪（APM），还需要网络可观测吗？

需要，两者看的是不同数据面。链路追踪告诉你"请求在服务 A 到服务 B 这一跳变慢了"，但它不知道这一跳慢在网络上哪个环节。网络可观测用的是连接级/包级数据（五元组、字节数、丢弃动作、路由路径），能回答"是跨可用区跳数增加、还是连接数超限、还是安全组在丢包"。先有链路追踪缩小到"哪一跳"，再用网络可观测回答"这一跳为什么慢"，是最省时间的组合。

Q2: 流日志降采样之后，还能定位问题吗？

看你要定位什么。趋势、画像、异常发现这三类完全不受影响——你要的是"某个方向的流量异常了"，而不是"第 12345 条记录长什么样"。但逐条取证（比如追一个具体攻击源的全部行为）需要全量，此时应改用流量镜像做短周期定点采集，而不是把流日志永久开到 100%。经验值是：生产核心 VPC 全量、非核心 VPC 1:10 采样、所有 VPC 出方向全量。

Q3: 流量镜像和流日志，只用一个行不行？

不行，它们的分工不可替代。流日志给你广度（全量连接、长期留存、便宜），流量镜像给你深度（完整载荷、协议级细节、昂贵）。只用流日志，你会在"为什么这个 TCP 连接一直握不上手"这类问题上卡住；只用流量镜像，你的账单会失控且没有历史基线。正确组合是：流日志常开做基线，流量镜像按需短开做深挖。

Q4: 跨云网络可观测，统一分析面必须自建吗？

截至目前，三朵云没有任何一家提供跨云的原生网络统一视图。AWS 的 Network Manager、阿里云的 NIS 都只管自己家的云。所以统一分析面只有两条路：一是自建（各家流日志就近落地到对象存储/日志服务，再用 OpenSearch 或 ClickHouse 做归一化查询），二是用第三方可观测平台的采集器（把三家的流日志都采集到同一个后端）。小团队建议走第二条，人力成本更低；有平台工程能力的团队走第一条，长期更可控。

Q5: 为什么我的流日志账单远高于预期？

按以下顺序排查：① 目的地选错了——投递到日志服务比投递到对象存储贵，长期留存一定要走归档层；② 采样率没调——100% 采样在高流量 VPC 上会放大十倍；③ 跨地域投递——把异地日志投到中心地域，中间产生跨地域流量费；④ 短连接记录爆炸——大量 HTTP 短连接会产生海量记录，而长连接密集的业务（数据库、消息队列）记录数反而很少；⑤ 查询扫描量——未分区、未加保留策略的查询会单独计费。

Q6: 路径分析能不能挂成定时任务自动跑？

可以，但要克制。路径分析按"每次分析"计费，如果对每个实例两两组合做全量定时评估，费用会迅速失控。推荐做法是事件驱动：只在路由表、安全组、NAT 网关、VPC 端点发生变更后触发一次分析，或者对"关键业务路径"（例如入口到核心库的那几条）保持小规模的定期评估。

Q7: 网络数据算不算数据出境？可以跨境传输吗？

网络流量元数据（源/目的 IP、端口、字节数）在多数合规框架下被视为日志数据，一旦跨境传输同样受数据出境规则约束。因此工程上的铁律是：原始流日志不跨境，只汇聚归一化后的聚合事件。这与本站数据主权架构一文的原则一致——把"数据不出境"从制度要求变成架构属性，而不是靠事后审计兜底。具体合规判定请咨询法务，本文不构成法律意见。

Q8: 小团队资源有限，网络可观测先做哪三件事？

只做三件：① 三朵云全部开流日志并投递到本云对象存储（成本最低、覆盖面最广）；② 一条归一化 schema（把三家字段对齐，为将来的统一查询留好接口）；③ 三条高价值告警（出方向流量骤降、REJECT 突增、关键路径的最新一次路径分析结果）。这三件事做完，你已经能回答 80% 的"网络为什么不对"的问题。路径分析、流量分析器、拓扑可视化都可以后面再加。

总结

网络可观测性不是"再多买一个监控产品"，而是补上应用可观测之外缺失的那一层数据面。三条结论再强调一次：

1. 应用可观测与网络可观测是两套数据面，前者定位"哪个服务错"，后者定位"哪条路径坏"，缺一不可。 2. 成本几乎全在采集量与目的地——采样率是最大的杠杆，降采样能省 90% 而对定位能力损失极小；反而最容易失控的是按"非空 VPC·小时"和"ENI·会话小时"计费的存量型能力。 3. 三朵云没有统一的网络可观测产品，统一分析面必须自建或借助第三方，缺的那一块（尤其是腾讯云国际站的控制面能力）要在排期里显式留出工程量。

把流日志铺好、把字段对齐、把路径分析接进变更流程——这三步做完，你就能在下次"接口偶发超时、服务指标全绿"的时候，第一次真正把问题指出来。

> 🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。从多云网络可观测体系设计到三云落地实施，我们提供覆盖架构、合规与成本的一站式支持。