返回博客
·11 分钟阅读·productdevbook

Mac 上面向开发者与系统管理员的带宽监控

面向 macOS 开发者与系统管理员的实用带宽监控配置:进程级可视化、脚本接入与调试技巧。

  • Developer tools
  • macOS
  • Network monitoring
  • Sysadmin

本来 90 秒能跑完的测试套件跑了 14 分钟,CI 在超时。本地跑也慢。你接上性能分析器——CPU 没事。内存没事。然后你注意到测试 fixture 每次跑都在发几百个出站 HTTPS 请求,因为三个月前有人在 setup hook 里加了一次真实 API 调用,现在每个 PR 都在锤一个刚被限流的沙箱端点。带宽监控本来在第一天就能抓到。

对 Mac 上的开发者和系统管理员来说,网络可观测性是那种会复利的技能。一旦你知道哪个工具回答哪个问题,你就不会再为实际上是某个失控进程在做明显的事的问题浪费几小时。这篇是工作工具栈:什么时候上 tcpdump,什么时候上 Wireshark,什么时候上 nettop,什么时候上像 ova 这种按应用监控,以及怎么组合。如果你在搜"开发者 Mac 带宽监控",目标是实操的判断树,不是营销巡礼。

简要的四个层级

诊断工具横跨四个抽象层:

  1. 数据包字节tcpdump。线上每个字节加包头。最低层。适合捕获后分析。
  2. 数据包检视 — Wireshark。tcpdump 的数据被解码成可读的协议层。适合理解一个连接在做什么
  3. 实时按进程nettop。macOS 原生,按进程显示当前连接和速率。
  4. 按应用按时间聚合 — ova。菜单栏应用,可拖动历史,辅助进程归并。

用好它们的窍门是把层级匹配到问题。如果你问"我们的测试套件上周用了多少带宽",tcpdump 是错答案;ova 或类似的按应用历史工具是对的。如果你问"为什么这条具体的 HTTPS 连接慢",nettop 不会告诉你——你需要 Wireshark。

tcpdump:线上字节视角

tcpdump 每台 Mac 都有。它是合适工具的时候是:

  • 你怀疑特定协议问题(TLS 握手失败、重传、分片)。
  • 你需要捕获流量留待后续分析。
  • 你在没有图形工具的服务器级机器上工作。

一个有用的默认捕获:

sudo tcpdump -i en0 -n -s 0 -w capture.pcap
  • -i en0 — 在 Wi-Fi 接口捕获(两者都有的 Mac 上以太网用 en1,或检查 ifconfig)。
  • -n — 不解析主机名(更快得多)。
  • -s 0 — 捕获完整数据包,不只是包头。
  • -w capture.pcap — 写到 Wireshark 可读的 pcap 文件。

要过滤:

sudo tcpdump -i en0 -n 'host api.example.com and port 443'
sudo tcpdump -i en0 -n 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'

第一个只捕获到特定主机名的 HTTPS 流量。第二个只捕获 TCP 连接建立/拆除——用来计连接数而不被载荷字节淹没。

Wireshark:协议解码

Wireshark 读 pcap 文件并解码成可读的层级:以太网帧、IP 数据包、TCP 段、TLS 记录、HTTP 请求。免费、本地、无云组件。通过 Homebrew 安装:

brew install --cask wireshark

显示过滤器语言是其魔法。几个高影响过滤:

  • http.response.code >= 400 — 显示失败的 HTTP 响应。
  • tcp.analysis.retransmission — 显示 TCP 重传,常是网络拥塞或对端问题的征兆。
  • tls.handshake.type == 1 — 显示 TLS Client Hello(每个连接一次)。
  • dns and dns.qry.name contains "example.com" — 显示对特定域的 DNS 查询。

Wireshark 对"Slack 今天用了多少带宽"是大材小用,但对"为什么这条特定连接 30 秒超时而别的成功"恰到好处。它也是当你从客户机器拿到一个捕获的 pcap 需要事后调查时的对的工具。

nettop:实时按进程视图

nettop 自带 macOS。它是按应用实时监控最近的内置等价物:

sudo nettop -P -m route

有用的标志:

  • -P — 按进程分组。
  • -m route — 显示路由信息(哪个接口)。
  • -x — 显示字节数(不只是速率)。
  • -c <interval> — 周期刷新,例如 -c 2
  • -J bytes_in,bytes_out,interface — 选择特定列展示。

nettop 是纯文本,刷新自己的屏幕,能在 SSH 上工作。它在你需要快速回答"远程 Mac(CI runner、你 SSH 进去排查的同事机器)现在有没有什么奇怪"时是对的工具。

缺点:nettop 没有历史。一旦退出,数据没了。

ova:按应用的历史与辅助归并

ova 驻在菜单栏,提供 nettop 没有的:持久化历史、可拖动时间线和辅助进程归并。约 1 Hz 采样,数据写到本地,删之前都在。

ova 做了内置工具不做的两件事:

  1. 辅助进程归并。 Chrome 每个标签创建一个辅助 PID;Slack 有自己的辅助架构;Discord、Telegram、一般来说 Electron 应用都这样。nettop 把它们显示成单独行("Slack Helper (Plugin)"、"Slack Helper (GPU)" 等),技术上正确但不可读。ova 把它们归到 "Slack" 下,所以那行就是你实际想说的。
  2. 可拖动历史。 "上周二下午 3 点发生了什么"通过点击拖动时间线就能回答。nettop 的答案是"我不知道,我没在跑"。
辅助进程归并
ova 把每个辅助 PID 归到它的父应用下,所以你读 "Slack" 而不是七行辅助。

对开发者的日常——"构建是不是锤了 registry"、"哪个测试拉了 4 GB"、"每个整点的那个反复尖峰是什么"——ova 不啰嗦地快速给答案。当你需要"现在就要、不装东西"时 nettop 是后备。

具体例子

调试 API 锤击

一个团队抱怨 staging API 慢。你怀疑某个客户端在重试循环里。在出问题的开发者 Mac 上的 ova 菜单栏里,你拖到慢的时候看到团队的 CLI 工具峰值 80 MB/s 持续 15 分钟。这是线索。在一段 30 秒捕获上打开 Wireshark 确认:每个请求拿到 503,客户端以 100 ms 退避在重试。bug 在重试策略——指数级,不是常数——现在你确切知道修什么。

找出失控的测试进程

CI 没事但本地测试跑得慢。打开 ova,跑套件,拖到尖峰。你看到 node 在 30 秒窗口里拉了 200 MB。tcpdump 过滤到可疑端口显示测试 fixture 每次测试都在从真实 CDN 取活数据,而不是用录好的 fixture。换成本地 fixture,套件回到 90 秒。

厂商库的意外出站

合规审查问代码库有没有在哪里偷偷往家发数据。静态分析只能给出部分答案;唯一确定的回答是"在代表性使用时盯着网络"。用 ova 跑应用一小时;用 tcpdump 同一小时捕获以校验。交叉核对 nettop 主机名列里看到的目的地。任何意外都要查。这种审计没有按应用历史就难做。

系统管理员舰队里失控的同步代理

内部 Slack 消息:"我 Mac 感觉慢"。你 SSH 进去,跑 sudo nettop -P -m route。一个所有人忘了装的备份代理在做完全重新索引,持续 30 MB/s。kill 守护进程,开 ticket 修日程。五分钟修法,没合适工具就要一小时。

看 ova 实战

一眼可瞄的菜单栏带宽监控——本地、签名、约 3 MB。

下载 macOS 版

可脚本化的钩子

用于自动化:

nettop 类 JSON 输出

nettop -P -L 1 -k state,interface_name,rx_dupe,rx_ooo,re-tx,rtt_avg,rcvsize,tx_win,tc_class,tc_mgt,cc_algo,P,C,R,W -J bytes_in,bytes_out

这产生一个样本(-L 1 标志),你可以在脚本里捕获。整形后管道到 awkjq

带宽阈值

围绕 nettop 可以快速搭一个"任何进程超过 X 就告警"的脚本:

sudo nettop -P -L 1 -J bytes_in,bytes_out -k state,interface_name,P,C,R,W \
  | awk 'NR>1 && ($2+$3) > 1000000 {print}'

(粗糙,但能用。)生产质量版本看 iftop 做按主机流量或 bmon 做接口级别。

tcpdump 作为看门狗

sudo tcpdump -i en0 -n 'host suspicious.example.com' -w "/tmp/capture-$(date +%Y%m%d-%H%M).pcap" -G 3600 -W 24

按 1 小时滚动捕获文件,保留 24 个。"我不知道这事什么时候发生,但下次想抓到"时有用。

ova 导出

ova 把历史写到本地。如果你要把它喂进面板或报告,导出路径是合适的起点——数据是你的,中间没有厂商同步层。

怎样选择开发者 Mac 工作流真正需要的带宽监控

一个简短矩阵:

问题合适工具
现在谁在用我的网络?nettop、ova
昨天下午 3 点谁用了我的网络?ova
为什么这条具体 TCP 连接慢?Wireshark
有 TLS 握手失败吗?Wireshark
上周总字节数是多少?ova
进程 X 在跟主机 Y 通信吗?nettop、tcpdump
留待事后取证审查?tcpdump → pcap
通过 SSH 做一次性远程诊断?nettop

规律是:nettop 和 ova 回答"什么"和"什么时候",tcpdump 和 Wireshark 在协议级别回答"为什么"。多数开发者面向的问题不打开 Wireshark 也能回答——那是低频工具,留给真正令人困惑的协议问题。

系统管理员特有的规律

如果你维护一支 Mac 舰队(小团队、设计工作室、视频店),规律不一样:

  • 先发现。 通过 SSH 或远程管理在每台机器上跑 sudo nettop -P -m route,看在跑什么。找不熟悉的进程——浏览器扩展、捆绑广告软件或被遗忘的 Beta 软件的特征信号。
  • 重度用户的历史。 对团队里网络重度用户(上传 dailies 的视频剪辑师、推大产物的开发者),按应用的历史工具能在它们发生的当下不在场也抓到反复出现的问题。
  • 有文档的基线。 捕获一台"好"Mac 和一台"投诉中"的 Mac 的 nettop 输出。差异通常很明显。

接下来做什么

如果你从零开始一个开发者 Mac 带宽监控工具栈,装 ova 做常驻历史视图,学上面三条 nettop 咒语,把 Wireshark 加书签留待需要时用。这就是工作集。开发者或系统管理员一天里多数问题在按应用或按进程级别就能解决;包级别工具是给每月才出现而不是每天的更难案例准备的。

测试套件锤 API、失控的同步代理、每次构建偷偷下 8 GB 的 CI runner——这些一旦有合适工具开着就立即可见。代价是几分钟设置。回报是下次某个东西"无故慢"时答案在菜单栏里,而不是两小时的性能分析器猎杀。