日本服务器丢包排查看哪些日志与指标？如何关联MTR结果和网卡计数

日本服务器丢包排查不能只看 MTR 某一跳的 Loss 百分比。中间路由器可能限制或降低对探测报文的响应优先级，导致该跳显示丢包，但后续节点和业务连接正常；更有价值的线索，是终点丢包是否同步出现、网卡错误计数是否在同一时间增长，以及系统日志和业务指标是否出现对应变化。

建议按“确认业务现象—对齐时间—检查网卡与系统计数—对照 MTR 路径—复测”的顺序排查。MTR 用来观察到目标的路径和探测响应，网卡计数用来判断服务器接口是否出现收发异常，系统日志则帮助定位链路状态变化、驱动或内核告警。三类信息必须放在相同时间窗口内比较，单独一项通常不足以确认故障位置。

先明确丢包指标代表什么

丢包不是一个单一指标。用户侧的请求超时、MTR 的节点 Loss、服务器网卡的错误计数，以及 TCP 重传，反映的是不同位置、不同类型的现象。

Linux 的不少网卡统计值是自启动或驱动加载以来累计的。排查时关注的是统计值在观察窗口内的增量，而不是某个孤立的累计数字。例如，rx_errors 长期为 100，但持续数小时不再增长，和 5 分钟内从 100 增至 2,000，含义截然不同。

还要区分网卡“接收到的包”和服务器“收到的探测回应”。MTR 发出的探测报文经过多个路由节点，每个节点通常需要单独生成回应；中间节点不回应或限速，不代表它没有继续转发后续报文。判断路径丢包时，应特别看后续节点和目标端是否持续出现相同问题。

排查前先对齐时间与测试条件

开始采集前，记录服务器时区、系统时间、发生故障的起止时间、受影响的业务地址和端口，以及测试端所在网络。若用户反馈时间是本地时间，应先确认时区后再和服务器日志对照。可用以下命令检查系统时间与同步状态：

date -u
timedatectl status

如果服务器与测试端时钟有明显偏差，日志和 MTR 结果就可能无法准确对应。不要为排障直接手工修改系统时间；先核对时间同步服务状态，并按现有运维规范修复同步，再进行时间线分析。

Linux 上每次采集应尽量保持相同的目标地址、协议、探测间隔和测试时长，并记录开始、结束时间。MTR 测试时间过短，样本量有限；测试时间过长，又可能跨越多个不同负载时段。日常定位可先连续测试约 2 至 5 分钟，再根据故障持续时间延长。这个范围是排查时便于观察的参考，不代表任何网络的性能承诺。

有条件时，同时记录业务请求的成功率、延迟、并发量，以及服务器的 CPU、内存、磁盘 I/O 和网络吞吐。若请求量或 CPU 在同一时段突然上升，应用响应变慢可能导致客户端超时，表象看起来像网络丢包，但根因未必在链路。

按优先级检查服务器日志与计数

以下命令以常见 Linux 服务器为例。命令主要用于读取状态，不会主动修改网络配置；journalctl、ip、ethtool、nstat 和 sar 的可用性取决于发行版与已安装工具。先检查命令是否存在，不要为运行单次排查命令直接升级内核或替换网卡驱动。

1. 检查接口状态和收发计数

先确认业务流量实际经过哪个接口：

ip -br link
ip route get 目标IP

将“目标IP”替换为要测试的业务目标地址。ip route get 会显示本机到该地址所选路由和接口，可避免只检查了并未承载该流量的网卡。

读取接口的基本计数：

ip -s link show dev eth0

将 eth0 替换为实际接口名。输出中的 RX 和 TX 通常包括数据包数、字节数、错误和丢弃数。再查看系统导出的接口统计：

cat /proc/net/dev

关注以下字段，并在两次采样之间比较增量：

• RX errors、TX errors：接收或发送错误。需结合驱动计数进一步拆分。
• RX dropped、TX dropped：接口或内核统计到的丢弃。发生原因可能是缓冲区不足、队列拥塞或其他接口处理问题，不能仅凭该字段认定线路损坏。
• overruns、missed：接收处理跟不上或硬件接收队列来不及处理时，部分驱动会记录相关计数。
• carrier、发送超时等：可能与链路状态、驱动或接口重置有关，但字段名称和定义受网卡驱动影响。

间隔 60 秒采两次，示意如下：

date -u
ip -s link show dev eth0
sleep 60
date -u
ip -s link show dev eth0

例如，第一次 RX dropped 为 20,000，第二次仍为 20,000，说明这 60 秒内该字段没有增加；若变为 20,600，则需进一步确认这段时间业务流量、CPU 负载和驱动统计是否同步异常。累计值较大并不自动等于当前故障，增量、时间和业务现象的对应关系更重要。

2. 检查驱动与链路事件

通用接口计数不足以解释原因时，再查看网卡驱动提供的详细计数：

sudo ethtool -S eth0

常见字段可能包括 rx_crc_errors、rx_missed_errors、rx_no_buffer、tx_timeout 或队列相关统计。不同网卡与驱动的字段名并不统一，具体含义应以该驱动的统计定义为准。重点看：

• CRC、校验或帧错误是否持续增加；
• 接收队列未能及时处理、缓冲区不足等计数是否在故障窗口增长；
• 发送超时、队列停滞或接口重置是否与业务异常同时出现；
• 多个队列是否只有单一队列异常，还是整体都在增长。

查看内核日志中的网卡和链路事件：

sudo journalctl -k --since "2026-10-02 10:00:00" --until "2026-10-02 10:15:00"

将时间范围改为故障发生的实际时间。也可按关键词初步筛查：

sudo journalctl -k --since "30 minutes ago" | grep -Ei 'link|carrier|reset|timeout|NETDEV|eth0'

重点找接口状态变化、链路断开与恢复、驱动重置、发送队列超时、内核网络设备告警等记录。不同发行版对日志的保存方式可能不同；若 journalctl 没有相关记录，可按系统实际使用的日志服务检查内核日志文件。不要仅因某个关键词出现就下结论，应核对日志时间、接口名称和计数变化。

例如，日志显示接口在 10:04 断开、10:04 恢复，且同一窗口内网卡错误计数跳增、业务连接失败率升高，这些证据彼此吻合，才更支持接口或驱动方向的进一步排查。若日志无异常，也不能据此排除上游链路或网络路径问题。

3. 检查主机网络栈、重传和处理压力

服务器网卡没有明显错误时，可检查内核网络统计：

nstat -az

常见 TCP 相关计数包括 TcpRetransSegs 等；IP 层可能有接收丢弃或错误计数。它们通常也是累计值，而且作用范围可能是整台主机，并非某一业务连接。应在同一观察窗口记录前后值，比较增量，并结合业务连接数量、流量和目标地址判断。

若系统已安装 sysstat，可检查接口吞吐、错误和丢弃趋势：

sar -n DEV,EDEV 1 60

该命令按 1 秒间隔采集 60 次；不同版本支持的报告项可能略有差别，可先用 sar -n 查看本机支持项。关注接口收发速率是否逼近可用带宽、错误或丢弃是否增加，以及异常是否与高峰负载重叠。

CPU 和 I/O 也应纳入判断：

uptime
vmstat 1 10

如果 CPU 长时间繁忙、运行队列明显升高，或软中断处理集中在单个核心，主机可能无法及时处理大量网络报文。内存不足、频繁回收或应用阻塞也可能放大请求超时。磁盘 I/O 通常不会直接造成 IP 层丢包，但若业务服务依赖磁盘，I/O 等待可能延长响应时间，使调用方误判为网络故障。

4. 检查业务层记录

网络排查不能忽略业务日志。根据服务类型，查看访问日志、应用日志和连接池记录中的时间戳、请求路径、客户端或上游地址、状态码、处理耗时、连接超时和重试次数。若日志只显示应用处理耗时变长，而服务器接口计数和 MTR 目标端没有异常，应继续判断应用负载、数据库响应和磁盘 I/O，而不是直接归因于链路丢包。

若业务请求日志显示连接阶段超时，且同一时间 TCP 重传上升、目标端 MTR 也有异常，网络方向的证据更强。若连接已建立但服务端处理耗时增加，问题可能发生在应用处理阶段。日志字段名称依具体软件而异，应确认其含义，例如“总耗时”是否包含连接建立时间，避免把不同阶段混在一起比较。

用 MTR 判断异常发生在哪一段

在 Linux 测试端执行 MTR。通常先用 ICMP 探测，目标为业务服务器的实际地址：

mtr -rwzc 100 -i 1 目标IP

参数含义：-r 输出报告后退出，-w 使用较宽的报告格式，-z 显示自治系统信息（若本机支持），-c 100 发送 100 轮探测，-i 1 为每轮设置约 1 秒间隔。具体参数支持情况以本机 mtr --help 为准。

报告中常见字段的含义如下：

• Loss%：该跳探测未收到回应的比例。只看中间一跳的百分比不能确认转发丢包。
• Snt：发送的探测数。样本数太少时，少量未回应就会造成较大的百分比波动。
• Last、Avg、Best、Wrst：最近一次、平均、最低和最高回应延迟。高延迟峰值可能是瞬时拥塞或响应排队，不能单独判定丢包。
• StDev：回应延迟的波动程度。数值升高说明时延变化较大，但不直接等于丢包。

判断时从上游到目标逐跳比较：

1. 某一中间跳显示高 Loss，后续跳和目标端无 Loss，业务正常。

更像该节点对 MTR 探测回应进行限速、低优先级处理，或选择不回应。通常不应仅凭这一跳要求调整服务器配置。

1. 从某一跳开始，后续多跳及目标端持续显示相近的 Loss。

说明异常可能出现在该跳附近之后，但仍需和另一测试时段、另一端结果及业务指标对照。路由路径可能存在不对称，单端 MTR 不能精确指出双向业务流量的故障位置。

1. 只有目标端出现 Loss。

可能是目标主机对探测报文的处理、主机负载、末段路径或探测类型差异导致。应结合网卡计数、业务连接结果及目标端对相应协议的响应情况继续判断。

1. 各跳延迟都升高，但 Loss 不明显。

重点检查时延变化是否与业务请求耗时同步，并排查拥塞、服务器负载或应用处理时间。高延迟和丢包不是同一指标。

ICMP 探测与业务协议的处理策略可能不同。若业务依赖 TCP 服务，可在测试端使用 MTR 的 TCP 模式，按本机版本核对参数，例如：

mtr -T -P 业务端口 -rwzc 100 -i 1 目标IP

其中 业务端口 替换为实际端口。TCP 模式更接近对相应 TCP 端口的探测，但也不等同于真实业务请求；探测结果仍可能受防火墙策略、服务端负载和探测频率影响。进行对照时，ICMP 与 TCP 测试应分别记录，不能把两种模式的数字直接当成同一种测量结果。

把 MTR、网卡计数和日志放进同一条时间线

将数据对齐后再作判断。每轮记录至少应包含：UTC 时间、MTR 开始与结束时间、目标地址、探测类型与数量、网卡 RX/TX 错误和丢弃的前后值、内核日志事件、CPU 与网络流量，以及业务失败率和延迟。

下面是一组用于说明判断方法的模拟记录，不代表特定服务器的实测结果：

这组记录表明，MTR 目标端异常与业务超时在时间上重合，而接口接收丢弃也在相同窗口增加，服务器接收方向值得优先调查；但仍不能据此确认具体原因。还需要确认驱动详细计数、主机负载、流量是否超过处理能力，以及其他测试端是否观察到同一目标异常。

另一种常见情况是：MTR 第 3 跳 Loss 为 40%，后续各跳及目标端均为 0%，服务器网卡计数没有增长，业务也正常。这种结果更符合中间节点不稳定回应探测，而不是目标服务器发生持续丢包。此时继续反复调整服务器网络参数，反而可能增加故障风险。

时间线最好采用一分钟或五分钟粒度，具体取决于故障持续时间。网卡累计计数至少保存两次快照；MTR 记录测试区间，而不是只留最后一张报告。若日志使用本地时区、监控使用 UTC，应先转换到同一时区再比较。对于很短的瞬断，可提高采样频率，但要注意频繁探测会增加无关流量，也可能触发设备对探测报文的限速。

按风险从低到高采取处理措施

排查时先做可观测性确认，再处理配置，避免把相关性误当成原因。

1. 确认接口与测试目标。 用 ip route get 找到实际出口接口，确认 MTR 目标与业务目标一致，记录故障时间、协议和端口。
2. 采集前后计数。 对比 ip -s link、ethtool -S 和 nstat 的增量，同时保留内核日志与业务指标。
3. 判断主机是否过载。 对照网络吞吐、CPU、内存、I/O 和请求并发；若异常只在负载峰值出现，应先核实资源瓶颈和接收处理能力。
4. 对照不同探测结果。 比较 ICMP 与 TCP MTR、不同时间窗口及业务真实请求。某个中间节点单独丢探测回应时，不应直接据此改动服务器配置。
5. 出现接口错误或链路事件时再升级处理。 若 CRC、接收队列溢出、发送超时或接口重置持续增长，先保存日志和计数，再按服务器运维流程联系网络或主机维护人员核对接口、驱动和上游端口状态。不要在生产环境盲目卸载驱动、重启网络服务或修改接口参数。

如果必须调整网络配置，应先保存原配置和当前接口状态，确认维护窗口、影响范围及控制台或带外访问方式，并准备恢复原值的回滚步骤。涉及重启接口或网络服务的操作可能中断远程连接，不适合在没有回滚通道时直接执行。若只是计数未清零，不建议为了“清空数字”重启网卡；记录时间点并计算差值即可。

修复后如何验证，何时可以停止排查

修复后应在与故障时尽量一致的条件下复测：同一目标地址、相同探测协议、相近探测时长和相似业务负载。连续观察至少覆盖一段有代表性的业务周期；若问题只在高峰出现，低负载下短暂正常并不足以证明已修复。

验证时重点比较以下内容：

• MTR 目标端是否持续恢复，异常是否仍只出现在不影响后续路径的中间跳；
• 网卡错误、丢弃和驱动详细计数在新观察窗口内是否停止增长；
• 内核日志是否不再出现接口断开、重置或发送超时；
• TCP 重传、业务超时率和请求延迟是否回到故障前的常态区间；
• CPU、网络吞吐和并发量是否处于可持续水平，而不是靠短时低负载掩盖问题。

如果业务已恢复、目标端探测稳定、网卡错误计数无新增，且日志没有新的链路事件，可以认为当前观察窗口内没有复现故障；这不等于证明所有路径和时段都永远正常。若 MTR 仍在某个中间节点显示 Loss，但目标端、业务请求和服务器计数均正常，应以端到端结果为主，并保留测试时间与输出，便于后续复核。

容量判断也要结合多个指标：若网络吞吐长期接近可用上限、接收丢弃在高峰随并发增长、CPU 或软中断处理同时繁忙，优先考虑服务器处理能力或流量峰值是否超过当前配置的承载范围；若吞吐和主机负载都不高，但目标端 MTR、业务超时与接口错误在同一窗口持续出现，则更值得沿链路和接口方向继续定位。最终判断应依赖同一时间线上的多项证据，而不是单看一个 Loss 百分比或一条累计计数。