家庭与小型网络应该监测什么？
实用的家庭或中小企业网络监控不能只看设备是否在线。应该从用户真正使用网络的位置， 同时监测本地网关、互联网质量、DNS、重要服务、Wi-Fi 或链路状态以及设备健康，并保留 足够的历史，用来对比正常时段与故障前后的几分钟。
这些信号组合起来，回答的就不再只是“路由器在线吗”，而是：哪一层发生了变化、 从谁的视角发生、同一时间还有什么一起变了？
值得监测的六个层次
| 层次 | 有用信号 | 典型问题 |
|---|---|---|
| 设备自身 | CPU、内存、磁盘、运行时间、网络吞吐 | 网络正常时，这台设备是否仍然因为自身负载而变慢？ |
| 本地链路 | Wi-Fi 信号与链路速率、接口状态 | 问题是否发生在设备到 AP 或交换机之间？ |
| 网关 | 可达性、延迟、丢包 | 流量还没进入互联网，本地网络是否已经不稳定？ |
| 互联网路径 | 延迟、丢包、抖动、路径诊断 | 上行链路是否恶化，路由是否发生变化？ |
| 域名解析 | DNS 响应与结果正确性 | 设备在建立连接前，能否正确找到服务？ |
| 应用服务 | TCP 连接、TLS 握手、HTTP 响应 | 网络整体可用时，是否只有某个服务或协议层失败？ |
不需要在每台设备上采集所有信号。真正的价值来自少量相互重叠的测量，它们刚好足以区分 几类可能原因。
从一组精简目标开始
每个监测地点可以先选择代表不同故障边界的目标：
- 本地网关。 用它区分本地链路或路由器问题与上游问题。
- 稳定的公网 IP 目标。 不依赖 DNS，单独观察互联网路径。
- DNS 解析器。 把域名解析和普通网络可达性分开测量。
- 用户真正依赖的一项服务。 检查对应的 TCP、TLS 或 HTTP 层，不要因为 ICMP 有回复就假设应用一定正常。
- 端点本身。 在平台允许时保留本地链路与主机状态。
只探测你有权访问的公网目标，并使用克制的间隔。更多目标、更高频率不一定带来更多信息， 反而可能增加噪音与无意义流量，让关键模式更难看清。
把测量点放在故障会产生差异的位置
测量点的位置和指标本身同样重要。路由器旁边的监控设备很适合观察上行链路，却无法说明 另一个房间里的笔记本正经历怎样的弱 Wi-Fi。云端监控能看到公网服务是否响应，却看不到 本地 DNS 解析器或家庭网关是否失败。
一种实用的安排是：
- 网关附近放一个常开测量点。 OpenWrt 路由器、小型服务器或 NAS 可以持续保留这个地点及其上行链路的视角。
- 重要用户设备上放一个测量点。 它能暴露单看网关无法发现的 Wi-Fi、设备负载和本地差异。
- 每个远程地点至少放一个。 办公室、工作室、家庭或附属建筑的上行链路可以独立故障，需要各自的本地视角。
NetTact 直接采用这种模型：Agent 在每个地点执行探测并把测量推送给 Server；Server 不会 主动连接 Agent，也不会把所有探测都放在自己的网络中执行。
组合读取信号，不要孤立地看一个数字
一次测量很少能证明原因，多个同时变化的信号更有价值：
| 观察到的模式 | 下一步优先检查的范围 |
|---|---|
| 只有一台 Wi-Fi 设备到网关的延迟或丢包升高，有线设备正常 | 该设备的 Wi-Fi 链路、干扰、漫游或所关联的 AP |
| 网关一直稳定，但多台设备同时无法访问同一公网目标 | 路由器 WAN、光猫、ISP 上行或更远的路径 |
| 公网 IP 检查正常，DNS 检查失败 | 本地或指定的 DNS 解析器、转发、过滤或 DNS 传输 |
| 网络检查正常，但 TCP、TLS 或 HTTP 失败 | 目标服务、端口、证书、代理或应用层 |
| 只有一台设备变慢，同时主机负载上升 | 设备资源压力、本地软件或接口饱和 |
| 所有地点都看见同一个远端服务失败 | 远端服务或多个地点共享的上游依赖 |
这些模式只能指向下一项检查，不能自动证明根因。路由器可能限制诊断流量，服务可能区别 对待不同协议，去程和回程也可能不对称。
先建立基线，再调整告警
不存在适用于所有网络的统一“良好延迟”。附近的有线网关、卫星互联网路径和远程办公室 VPN 的正常范围完全不同。先收集普通工作日、繁忙时段与空闲时段，再用用户能理解的行为 描述告警，例如：
- 网关持续不可用，已经足以影响正常使用；
- 互联网延迟持续明显高于这个地点的日常范围；
- 丢包连续出现在多次检查中，而不是只出现一次；
- 基本互联网可达性正常时，DNS 仍反复失败；
- 同一地点其他设备在线时，某台 Agent 停止上报。
这样既不会因为一次无害尖峰就报警，也会把尖峰保留在历史中供之后排查。NetTact 内置的 可用性与 Agent 连接检测会把确认故障形成事件，并把未达到故障条件的波动保存为可能的前兆证据。
保留足够历史来定位间歇性故障
故障进行时，实时面板很有用；但间歇性问题常在任何人打开面板前就恢复。历史应该能够回答：
- 哪些设备和地点在同一时间发生变化？
- 公网目标失败前，网关质量是否先恶化？
- DNS 是否在 IP 可达性正常时独立失败？
- 应用变慢前，Wi-Fi 或设备负载是否变化？
- 网络路径是否变化，恢复又从何时开始？
因此，把测量、故障证据和恢复连接到同一条时间线，比单独一个红色或绿色状态更有用。
隐私与访问边界
监控软件可能看到敏感的基础设施信息。应当有意识地限制探测目标，不暴露不必要的 Agent 监听端口，并明确授予本地采集能力。在 NetTact 中，Agent 所在机器拥有采集和目标访问 策略；Server 能观察授权，但不能扩大它。自托管则让配置、指标与事件留在你运营的基础设施上。
增加进程、连接或主机状态采集前，先查看 NetTact 权限模型。基础网络 质量监控可以从较小权限集开始，只在额外证据确实有用时再扩展。
一套可执行的首次部署
对一个地点，可以先放置一台常开 Agent，再在一台日常使用的客户端上运行 Agent。监测 网关、稳定公网 IP、正在使用的 DNS 服务和一项重要应用。积累一段基线后，等真实症状出现， 再按定位间歇性网络问题的流程逐步收窄范围。
在一台 Windows 或 macOS 电脑上，NetTact Desktop是最快的一体化起点。 需要多台设备或多个地点时，使用自托管 Server，在每个有价值的测量位置 接入 Agent；OpenWrt Agent则可以直接提供常开的网关视角，不必新增一台机器。
相关标准
IETF 分别定义了往返时延、 单向丢包与 IP 包时延变化的正式度量方法。家庭和小型网络 监控不需要复现实验室测量系统，但这些定义有助于避免把延迟、丢包和抖动当成同一个症状。