1. 深夜三点N100真机上的EOS日志又断了前几天凌晨监控群里一条告警把我从半睡半醒里拽了起来机房里那台N100小主机上的EOS服务日志在3点17分戛然而止心跳探活连续五次失败服务自动拉起后恢复但日志中间整整缺了四分钟。说实话这种莫名重启日志断档的戏码在低功耗小主机上不是第一次见了但每次都得老老实实从头查一遍。这台设备从去年底开始当边缘计算节点跑着EOS系统我们内部对那套边缘操作系统的代号上面挂着轻量数据库和几个数据采集服务24小时不关机偏偏每个月总要来这么一两出。所谓真机排查就是别在虚拟机里想当然得蹲在物理机面前把日志、内核、电源、BIOS挨个过一遍。这次我准备把完整的排查链路记录下来从日志怎么查看、怎么对齐时间轴到怎么定位根因、怎么配置持久化和采集再到那些只有真机上才会遇到的坑全部摊开讲。不管是跟我一样用N100系列迷你主机跑服务的还是家里NAS、软路由上跑各种自制服务的只要你的服务日志会莫名其妙中断这篇文章应该能帮你少走不少弯路。先说结论这次的问题拆到最后是两层叠加一是systemd-journald的易失性配置导致日志没落盘二是N100平台的电源管理策略在低负载时触发了S3睡眠两者凑一块儿日志就蒸发了。但排查过程远没有这么直白中间绕了不少弯下面按我实际操作的顺序从头讲。2. 第一步先弄清楚这台N100上的日志都写在哪2.1 EOS日志链路的基本盘排查日志问题第一件事不是去看代码而是先搞清楚这套系统上日志从产生到落盘的完整链路。EOS里跑的服务我分成三类系统服务systemd托管、应用服务写业务日志、内核输出dmesg/kmsg。三条线的终点各不相同系统服务日志默认走journald由systemd-journald统一收集应用服务一部分直接写本地文件比如/opt/eos/logs/下按天分割的*.log一部分往标准输出打被systemd捕获后转给journald内核日志通过dmesg读同样会进journald但优先级和时效性跟应用日志不一样。记住这个基本盘很重要因为后面排查时每一类日志都能作为独立的证据链。如果只盯着业务日志看很容易漏掉底层线索反过来如果只看journald业务日志里的业务语义又看不全。所以排查的第一件事就是把日志都在哪列成一张表心里有数再动手。当时我在这台N100上先执行了一遍ls -l /var/log/journal/ ls -l /run/log/journal/ journalctl --version df -h /var/log tail -f /opt/eos/logs/*.log注意看第一和第二个命令的输出。如果/var/log/journal/目录不存在或者里面是空的说明journald根本没有持久化——它把所有日志写在/run/log/journal/下这个目录是tmpfs一重启就全没了。我这次就撞上了这个情况。2.2 N100小主机的特殊之处N100是Intel的低功耗处理器TDP只有6瓦左右整机普遍用的是DC电源适配器或Type-C供电加上主板厂商为了省电默认开了各种节能选项。这种平台有个典型特征CPU性能够用但硬件层面的电源管理策略非常激进尤其是S3睡眠、USB唤醒、LAN唤醒这些选项稍有风吹草动就进入低功耗状态。对服务器来说这种省电模式恰恰是日志中断的重灾区——系统睡下去日志自然就不写了等被唤醒再起来中间的时间戳就断了。所以如果你也用的是N100系列的迷你主机、软路由、NAS板子排查日志问题时要多留个心眼不光是软件配置BIOS里的电源策略必须纳入检查范围。这一点虚拟机环境和云服务器是永远碰不到的只有真机才会给你来这么一下。3. 第一轮排查复现现象把能取到的日志都取一遍3.1 从dmesg看内核层有没有说真话我排查这类问题的习惯是先从内核层开始因为内核日志最底层也最不容易被应用层伪装干扰。N100小主机重启后,dmesg默认会带着本次启动以来的环形缓冲内容但如果上一次是异常掉电或者panic旧的dmesg信息可能已经丢了。好在这次是服务恢复、进程重启不是整个系统重启所以dmesg的内容还算完整。执行命令的时候注意加时间戳dmesg -T | tail -n 200用-T参数把内核时间戳换算成人类可读的日期时间这样能快速对齐3点17分左右发生了什么。我当时看到的内容里有一段很可疑[Fri May 17 03:17:21 2025] ACPI: PM: Preparing to enter system sleep state S3 [Fri May 17 03:17:23 2025] PM: suspend entry (deep)果不其然系统自己进入了S3睡眠根本没经过什么崩溃、OOM之类的戏码。这就解释了日志为什么在3点17分之后齐齐沉默——进程都跟着系统一块儿睡了。这条线索很关键接下来要做的是确认谁触发了睡眠。3.2 journald日志的断片问题此时再去journald里查3点17分前后的记录你会发现一个有意思的现象journald的时间戳是连续的但内容在某个节点后突然没有系统服务的输出了。原以为是journald挂了实际上在睡眠期间整个系统时间都冻结了journald本身并没有崩溃。在排查journald时有几个命令特别实用journalctl --since 2025-05-17 03:10:00 --until 2025-05-17 03:25:00 journalctl -u eos-core --since 2025-05-17 03:15:00 journalctl --list-boots第一条看完整时间窗内的所有日志第二条只看EOS核心服务第三条列出历次启动记录确认服务是不是被systemd重新拉起来的。要注意的是如果journald没持久化――list-boots只能看到当前启动的记录历史全丢。这次排查时我就发现boot记录只剩一条明显是journald把之前的日志都留在了tmpfs里随重启消失了。3.3 应用层EOS日志的表现EOS应用服务往/opt/eos/logs/写业务日志时是按小时滚动文件的正常情况下一小时一个文件。我查看3点前后时文件列表长这样-rw-r--r-- 1 root root 128765 May 17 03:16 eos-core.20250517-15.log -rw-r--r-- 1 root root 20480 May 17 03:24 eos-core.20250517-16.log16这个文件从3点24分才开始写入中间从17分到24分这七分钟完全没有文件产出。结合dmesg的睡眠记录时间轴完全对得上。此时基本可以用系统进入了睡眠来解释大部分现象了但还有一个问题没解开明明是一台服务器为什么会在凌晨自己睡眠N100默认的电源策略到底是谁在控制这个问题不查清楚就算这次手动改回来了下次还会再犯。4. 第二层排查真正的日志中断根因与时间轴还原4.1 把系统日志与应用日志对齐到同一根时间轴排查日志类问题最重要的一个习惯是同一根时间轴。系统日志用的是UTC时区或本地时区应用日志可能是自己格式化时间字符串两者如果基准不一致很容易得出错误结论。我一般在排查前先把所有日志源的时间基准拉齐date date -u timedatectl确认系统时区是Asia/ShanghaiNTP同步正常然后手工把两份日志的关键时间点列成一张表时间系统行为EOS应用行为证据来源03:16:58最后一条采集数据上报eos-core正常输出应用日志03:17:21ACPI准备进入S3journald日志中止dmesg -T03:17:23suspend entry (deep)无输出dmesg -T03:24:10系统被唤醒journald恢复记录--list-boots03:24:15eos-core被systemd拉起新日志文件创建应用日志对齐之后这张表就是整个排查的核心证据。很多时候不需要看几十万行日志只要把关键时间点列出来真相基本就浮出水面了。4.2 为什么N100会在凌晨自己睡过去接下来要回答的问题更关键系统为什么会主动进S3N100这块平台如果BIOS里开着C-States、S3睡眠并且系统的电源管理策略允许suspend那么在没有任何活动时它就可能睡过去。用日志里的线索倒推最常见的有这几类原因BIOS设置了定时唤醒/定时睡眠恰好凌晨某个时间点触发操作系统层面开启了suspend相关的电源管理服务外设事件触发比如USB设备、网卡唤醒。逐项排查时几条命令就能把范围缩到很小systemctl list-timers --all cat /sys/power/wakeup_count cat /sys/power/state cat /proc/cmdline我当时用systemctl list-timers查定时任务发现系统里跑着一个名为sleepschedule.service的定时触发器对应的timer正好在每天凌晨3点触发suspend。这是N100主板的厂商预装系统里带的一个贴心电源管理脚本专门在无操作时自动睡眠。这台设备平时跑的EOS服务大部分时间都在低负载就被这个脚本盯上了。这里插一句题外话真机排查和虚拟机最大的区别就在于真机上会有很多出厂自带的隐藏配置。你从镜像装机、从模板部署永远不会想到厂商会在系统里埋一个自动睡眠服务。所以遇到稀奇古怪的日志中断先别怀疑业务代码把厂商预装的服务和BIOS设置翻一遍往往更快。4.3 日志服务本身会不会也是帮凶除了系统睡眠我还顺便查了journald自身的配置和日志轮转状态因为就算没有睡眠问题journald也可能因为容量配置不当导致日志覆盖或停止写入。检查配置入口是/etc/systemd/journald.conf重点看几个参数grep -Ev ^#|^$ /etc/systemd/journald.conf正常情况应该关注SystemMaxUse、SystemKeepFree、MaxRetentionSec这几个选项。如果SystemMaxUse设得特别小比如默认的几十M日志很快会被轮转清掉时间一长你连现场都找不到。我在这次排查中看到SystemMaxUse被默认成auto即日志写满了分区可用空间的10%就开始清理虽然没有直接导致问题但这给后面的配置优化留下了一个隐患。5. 真机上的修复与加固让日志不再无声无息5.1 先杀掉自动睡眠的定时器找到元凶之后修复反而是最简单的事。把这个厂商自带的s3睡眠定时器关掉然后确保系统在服务运行期间不主动suspendsystemctl stop sleepschedule.service systemctl disable sleepschedule.service mask: systemctl mask sleepschedule.service顺手把BIOS里的电源策略也调整到Always On或S3 disabled级别。不同厂商BIOS布局不一样但核心思路是一致的既然这台N100是用来跑EOS服务的它就应该是一台服务器而不是一台会打盹的台式机。这说明配置替代码背锅的场景很常见把平台层面的自动电源管理关掉比去业务代码里找bug高效得多。5.2 journald持久化与容量规划针对日志刚才提到的易失性问题必须把journald改成持久化模式。这一步很多人会踩坑因为光改.conf不重启是没用的而且改之前还要建好目录mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal改/etc/systemd/journald.confStoragepersistent SystemMaxUse1G SystemKeepFree200M MaxRetentionSec30day然后systemctl restart systemd-journald journalctl --verify改完后的效果是journald会把日志写到/var/log/journal/下的持久化目录里重启不丢。SystemMaxUse根据自己的磁盘容量来定我给这台N100设备设了1G上限因为它的系统盘只有128G1G足够覆盖三十天的运行记录又不至于把根分区撑爆。这里多说一句capacity规划的原则是够用且可控——宁可多留一些余地也不要因为舍不得磁盘空间导致关键时刻没有日志。5.3 应用层日志轮转与采集配置journald管的是系统层业务日志还是得靠logrotate来轮转。EOS的日志都写在/opt/eos/logs/我在/etc/logrotate.d/下加了一个配置/opt/eos/logs/*.log { daily rotate 30 compress delaycompress missingok notifempty copytruncate }copytruncate是给那些一直打开文件句柄的应用用的复制内容到新文件同时清空原文件,应用不用重启。如果应用自己会重新打开文件可以考虑用create代替copytruncate两者各有适用场景。EOS的应用在写日志时句柄是持久的所以copytruncate更稳妥。5.4 用集中采集弥补单机日志的盲区单机日志再持久化也怕整机损坏或者磁盘故障。这次排查之后我把这台N100的日志接入了集中采集服务用filebeat把/var/log/journal和/opt/eos/logs的日志转发到中心日志面板。这样即使这台机器彻底挂了日志也在别处留了一份不会完全变成黑匣子。filebeat的配置比较直观关键是input和output两段filebeat.inputs: - type: log enabled: true paths: - /opt/eos/logs/*.log json.keys_under_root: true json.add_error_key: true - type: journald enabled: true seek: head output.logstash: hosts: [10.0.0.8:5044]重点是journald类型可以直接读systemd日志不占用额外磁盘也不需要跟logrotate打架。配合中心日志面板我可以在网页上按时间轴搜索整台N100的所有日志以后再遇到类似日志中断的问题不用蹲在真机前面了。6. 这次排查沉淀下来的通用检查清单折腾完这一趟我给自己列了一张真机日志排查的清单以后遇到类似问题直接照着走不需要再从零开始先确认journald是否持久化。查/var/log/journal目录是否存在不存在就是易失模式重启即丢用dmesg -T看内核睡眠/唤醒事件。S3、S4、hibernate这类关键词一旦出现优先查电源管理查系统定时器systemctl list-timers --all重点看有没有厂商预装的suspend/resume脚本关电源管理时连BIOS一起查。很多N100主板的ACPI设置是独立的系统层面关了不代表BIOS层面不触发业务日志和系统日志必须同一时间轴对齐。我习惯用表格列关键事件比盯着终端翻日志直观得多容量规划不要走极端。journald的SystemMaxUse、logrotate的rotate数量都要跟磁盘空间对齐宁可多留余量也不要卡着线配置。这些清单并不新颖但都是我这次真机排查里实际用到的步骤。尤其是第一条和第二条绝大多数日志莫名断档的问题都能在最初几步锁定方向。另外说个小细节这台N100在恢复运行后我还特意观察了几天确认凌晨三点不再有断片现象。后面如果再遇到类似情况我会先看中心日志面板的时间轴——如果所有日志在同一时刻齐齐消失那大概率又是平台层睡眠或者网络中断而不是业务代码的问题。排查日志问题的本质其实就是排查时间轴上的空白是谁制造的这个思路在真机上格外好用。