在企业全球 MPLS 专线运维过程中，网络链路稳定性一直是重点关注指标。本文记录一次香港专线质量监控异常事件：…
一、背景
我长期负责一张全球性的 MPLS 网络运维工作，为企业客户提供跨区域网络互联、专线服务以及网络质量保障。
对于企业专线来说，稳定性永远是核心指标。相比普通互联网业务，我更关注链路的连续性、低延迟、低丢包等。
日常运维中会部署多套监控系统，对不同区域、不同运营商、不同链路进行持续监测。
前段时间，由于网络有万分之一的随机性丢包，我新部署了一套 SmokePing 监控系统，用于监控香港区域专线的延迟、抖动和丢包情况。
每天早晨上班我都会查看前一晚的链路状态，这一个丢失的数据包，到底消失在网络的哪个环节？
这天，当我打开 SmokePing 时，却发现监控曲线出现了一段异常空白。
第一反应：
😱完了，是不是有地方挂了？登到PE设备上一顿操作，BFD正常、BGP正常、SRBE正常，网络没看到任何问题。
是不是DELL服务器有问题，查看idrac后台，查看NMS运维监控，0告警，控制器正常，网卡正常，所有状态全绿色。
还好 还好 不影响业务，剩下的慢慢查系统吧。
最终发现，问题并不在线路，也不在虚拟化环境，而是 Ubuntu Server 默认开启自动维护机制apt-daily-upgrade.timer导致的。
二、故障排查过程
2.1 系统排查
确认问题不在外部环境后，开始从系统日志入手排查。
首先查看 SmokePing 异常时间段的 Journal 日志：
journalctl -b 0 -p warning..alert --since "2026-07-28 06:53:00" --until "2026-07-28 06:55:30"日志显示：
Jul 28 06:54:15 smokeping systemd[1]: smokeping.service: Failed with result 'exit-code'.可以确认 SmokePing 服务是在 06:54:15 左右异常退出。
继续查看该时间段系统完整日志：
journalctl --since "2026-07-28 06:53:00" --until "2026-07-28 06:55:30"发现系统正在执行：
Starting apt-daily-upgrade.service - Daily apt upgrade and clean activities...随后 systemd 开始重新加载，并出现大量服务停止、启动记录。
这时基本确定，SmokePing 异常并不是自身运行导致，而是系统在执行某项自动维护操作时触发了服务变更。
2.2 确认自动更新内容
查看 apt 更新记录：
cat /var/log/apt/history.log发现：
Start-Date:2026-07-28 06:54:06
Commandline:/usr/bin/unattended-upgrade说明这次操作并不是人工执行，而是 Ubuntu 后台自动升级任务。
本次升级涉及：
Start-Date: 2026-07-28 06:54:06
Commandline: /usr/bin/unattended-upgrade
Upgrade: libc6:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8), locales:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8), libc-dev-bin:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8), libc-bin:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8), libc-devtools:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8), libc6-dev:amd64 (2.39-0ubuntu8.7, 2.39-0ubuntu8.8)
End-Date: 2026-07-28 06:54:14其中 libc6 是 Linux 系统核心运行库。
继续查看 dpkg 记录：
grep "2026-07-28 06:54" /var/log/dpkg.log
2026-07-28 06:54:06 startup archives unpack
2026-07-28 06:54:07 upgrade libc-devtools:amd64 2.39-0ubuntu8.7 2.39-0ubuntu8.8
2026-07-28 06:54:07 upgrade libc6-dev:amd64 2.39-0ubuntu8.7 2.39-0ubuntu8.8确认系统在 06:54 左右完成了 libc 相关组件升级。
2.3 找到真正原因
继续查看自动更新执行日志：
tail -50 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Restarting services...
systemctl restart apache2.service cron.service fwupd.service multipathd.service polkit.service postfix@-.service rsyslog.service smokeping.service ssh.service systemd-journald.service systemd-networkd.service systemd-resolved.service到这里，整个问题链路已经清晰：
Ubuntu 自动执行 unattended-upgrade 更新系统组件，随后 needrestart 检测到部分服务需要重新加载，于是自动执行服务重启，其中包括 SmokePing。
因此 SmokePing 并不是程序崩溃，也不是配置错误，而是在系统自动维护过程中被主动重启，导致监控数据出现了一段空白。
2.4 为什么 Ubuntu 会这样？
“Ubuntu Server 为什么会自动升级，还自动动生产服务？”Ubuntu 从较新的 LTS 版本开始，默认安 unattended-upgrades 用于自动安装安全更新。
官方说明：https://ubuntu.com/server/docs/about-automatic-updates
Ubuntu Server 默认开启：unattended-upgrades
主要目的是：自动修复安全漏洞；自动安装安全补丁。
同时 Ubuntu 使用：needrestart
项目地址：https://github.com/liske/needrestart
作用：当系统升级共享库（libc openssl systemd），旧进程仍然可能加载旧版本库。needrestart 会检查：哪些程序需要重新启动：
libc6 更新
↓
旧程序仍使用旧 libc
↓
needrestart 检测
↓
restart service2.5 为什么这次发生在 06:54？
查看 timer：
cat /lib/systemd/system/apt-daily-upgrade.timer
[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m每天，06:00 开始执行，随机延迟：最多 60 分钟。
2.6 解决方案
我的生产环境原则：监控系统、网络系统、生产服务，不应该由系统自动决定什么时候重启。
关闭自动维护：
systemctl disable --now apt-daily.timer
systemctl disable --now apt-daily-upgrade.timer
systemctl disable --now unattended-upgrades.service由人工维护窗口执行：
apt update
apt upgrade三、总结
本次 SmokePing 异常中断最终确认并非网络链路、服务器硬件或虚拟化环境故障，而是 Ubuntu Server 默认自动维护机制在凌晨执行更新过程中，由 needrestart 自动重启相关服务，导致系统时间状态异常，进而造成监控数据出现空白。
虽然 SmokePing 本身属于监控系统，对实际业务流量没有直接影响，但此次事件暴露出的风险属于底层系统维护机制问题。如果同类问题发生在承载生产业务的 VM 上，可能会对业务连续性造成影响。
因此，本着专业运维和风险可控的原则，需要对所有类似环境进行统一检查和优化，避免操作系统自动维护行为在未经评估的情况下影响运行中的服务，确保监控及业务系统长期稳定运行。
基于真实环境（扩展）整理，如需进一步沟通相关需求，可通过页面右侧方式与我联系。