拓冰网站定制 
干运维和开发这些年,Ubuntu 22.04 是我用得最久的 LTS 版本之一。 系统跑得越久,日志就越像个杂物间——你以为没用的东西堆了一地,可真要排查问题的时候,又翻不着关键的那一条。 这篇文章不聊虚的,直接讲透 Ubuntu 22.04 日志体系的底层逻辑,再把查看、清理、持久化、采集这些实操动作一个个拆开给你看。 不管你是刚接触服务器的初学者,还是已经被线上问题折腾过几轮的同行,这篇都能让你少走弯路。我先说一个很多人踩过的坑:以为日志就是/var/log下那一堆syslog、auth.log,然后tail -f里盯着看。 实际上 Ubuntu 22.04 引入了 systemd 之后,日志的主战场早就换到了 journald,/var/log里的文件更多是 rsyslog 从 journald 那边“接货”之后再落盘的产物。 如果搞不清这条链路,你会遇到两种典型症状:一种是journalctl里看不到东西,另一种是/var/log/syslog半天不更新,然后你开始怀疑是不是日志丢了。 其实都没丢,只是你站错了观察点。1. Ubuntu 22.04 日志体系与整体处理思路1.1 两条日志管线的分工逻辑Ubuntu 22.04 默认同时跑着两套日志收集系统,可以理解为一家公司里“前台接待”和“档案室”的关系。前台接待就是systemd-journald,它负责把内核日志、系统服务日志、各进程通过标准输出stdout/stderr打出来的信息全部接住,统一写进自己的二进制日志里。 这个二进制日志的存储路径默认在/var/log/journal/,不过 22.04 有个细节:如果这个目录不存在,日志会暂时落在/run/log/journal/,而/run是内存文件系统,重启就没了。 很多人在虚拟机上装好 22.04,跑了两天突然发现journalctl --since today能看到的东西变少,或者重启后查不到之前的开机日志,多半就是这个原因。档案室就是rsyslog,它从 journald 那边接收消息,然后按照配置把日志分门别类写入文本文件,比如auth.log、kern.log、syslog等。 它的配置在/etc/rsyslog.conf和/etc/rsyslog.d/下,默认规则已经分得很好,一般不用动。理解这条链路的意义在于:你在排查问题时,journalctl是获取原始日志的权威入口,而/var/log/下的文本文件是经过 rsyslog“加工”后的产物。 如果两边内容对不上,优先检查 journald 的配额有没有被写满、journald 是否处于持久化模式、rsyslog 服务是否还在正常运行。1.2 为什么选择 journald 作为核心很多人刚接触 journald 时觉得不适应,因为它的日志是二进制格式,不能直接cat,必须用journalctl来读。 但从工程角度看,这个设计是划算的——二进制存储带来了三个实在的好处:一是启动过程的早期日志也能被精准记录,不会因为服务依赖顺序而丢日志;二是可以用结构化字段做过滤,比如按服务名、PID、优先级、可执行文件路径来筛,这种维度是纯文本日志很难实现的;三是日志自带时间戳、主机名和单元信息,查问题时不用再靠肉眼去猜一条日志来自哪里。我在实际排障中有一个习惯:先journalctl -u 服务名 --since 10 minutes ago快速锁定服务状态变化,再去翻/var/log/syslog找上下游的联动痕迹。 这样的排查路径比直接开文件快得多。1.3 明确日志处理的目标场景日志处理不是一个单一动作,而是对应几种典型目标:问题追踪:某服务突然挂了,需要从日志里还原崩溃前的调用序列;安全审计:查看登录记录、sudo 操作记录,确认是否有异常 IP 尝试登录;容量控制:日志无限增长导致磁盘爆满,需要做轮转和清理;集中采集:多台服务器的日志要汇总到统一的日志平台如 ELK、Loki,便于集中检索和告警。不同目标对应的处理动作不一样。 如果只是临时排查,命令级别的操作就足够;如果要长期运维,就必须做 journald 配额限制、logrotate 轮转策略、乃至日志采集代理的部署。 这篇文章会按这条路径一步步展开。2. 查看日志:journalctl 与经典日志文件的实操要点2.1 journalctl 的高效用法journalctl是处理 journald 日志的唯一入口,但它的参数非常多,很多新手记不住。 我平时真正高频使用的就那几个组合,可以分三层来说。第一层是时间维度的过滤。 比如查昨天的日志,用journalctl --since yesterday;查最近五分钟,用journalctl --since 5 minutes ago;查固定时间区间,用journalctl --since 2024-06-01 10:00:00 --until 2024-06-01 12:00:00。 时间的写法很灵活,支持today、yesterday、tomorrow,也支持-1 hour这类相对时间。 我强烈建议你把时间过滤当成肌肉记忆,因为生产环境日志量大的时候,不带时间参数直接journalctl,输出会大到让你怀疑人生。第二层是单元维度的过滤。 查某个服务的日志,用journalctl -u ssh.service;查某个服务的最近日志并持续跟踪,用journalctl -u nginx.service -f。 这比去/var/log/nginx/error.log翻文件更全,因为 journald 会把服务启动早期、进程 stdout 输出的内容全都收纳进来,而应用自身的日志文件往往只记录了应用认为“值得记录”的内容。第三层是优先级过滤。 日志级别从上到下是emerg、alert、crit、err、warning、notice、info、debug,用journalctl -p err就能只看错误及以上级别的日志。 这里有个小技巧:-p err实际上是“err 及以上”,也就是会把 crit、alert、emerg 也带出来。 排查问题时先journalctl -p err -since today,如果没发现,再放宽到warning,这种“从高往低放宽”的顺序能帮你快速定位异常。2.2 经典日志文件怎么配合着看虽然 journald 更强,但有些场景下文本日志依然不可替代。 比如sudo的所有执行记录只会出现在/var/log/auth.log里,journalctl | grep sudo虽然也能找到,但效率和准确性都不如直接查auth.log。Ubuntu 22.04 下值得关注的日志文件主要有这几个:/var/log/syslog:系统全局日志,几乎所有经过 rsyslog 的消息都会汇总在这里;/var/log/auth.log:认证与授权日志,登录、sudo、SSH 密钥校验都在这里;/var/log/kern.log:内核日志,硬件问题、驱动报错通常在这里;/var/log/dpkg.log:软件包管理日志,apt install和dpkg的痕迹都在这;/var/log/boot.log:开机启动过程的日志。我在排查 SSH 登录问题时有个固定动作:先grep Failed password /var/log/auth.log,统计失败次数和来源 IP,再配合journalctl -u ssh --since today看完整的连接过程。 前者适合做安全审计,后者适合做问题溯源,两个视角互相补充。2.3 日志量太大时先做什么日志量大的时候,最忌讳的就是直接cat整个文件。 我见过有人对几百兆的syslog执行cat,结果终端卡死,不得不强制重开会话。 正确的顺序一定是“时间过滤 关键词过滤 翻页查看”三件套,比如这样:journalctl --since 30 minutes ago | grep -i error | less如果觉得每次敲一长串命令太麻烦,可以给常用的查询做别名,放进~/.bashrc:alias jerrjournalctl -p err --since today alias jserjournalctl -u sshd --since today alias jalljournalctl --since 10 minutes ago这样每次排查的时候只需要输入两三个字母就能开始,效率提升非常明显。2.4 查看 crontab 执行日志的方法这个需求在热词里出现频率很高。 Ubuntu 22.04 里 cron 的实际执行日志默认走 rsyslog,会写进/var/log/syslog,可以用grep CRON /var/log/syslog来看。 但生产环境 syslog 经常轮转得很快,很多时候你想查的那几条已经被轮转掉了。更可靠的方式是检查 cron 任务自身有没有把输出重定向到文件。 比如你的 crontab 里写的是0 2 * * * /opt/backup.sh,那脚本的标准输出默认会被 cron 吞掉。 想追踪执行情况,最稳妥的做法是改成这样:0 2 * * * /opt/backup.sh /var/log/backup.log 21同时在脚本里加执行时间戳:echo $(date %Y-%m-%d %H:%M:%S) backup start /var/log/backup.log这样一来,任务的执行记录就不依赖系统日志轮转了,任何时候都能回溯。 我在实际运维中,凡是新建 cron 任务,第一件事就是确认输出有没有落到固定文件,这一步能省掉后续大量的排查时间。2.5 日志时间不对怎么处理Ubuntu 22.04 默认使用 UTC 时间,如果你的服务器时区设置不对,会发现日志时间和你本地时间对不上。 处理方式很简单:sudo timedatectl set-timezone Asia/Shanghai执行完可以date验证一下。 注意 journald 对时区变化是敏感的,改完时区后最好重启一次 journald 让时间戳刷新:sudo systemctl restart systemd-journald这里要提醒一点:千万不要把时区问题和日志丢失混为一谈。 有时你用journalctl --since 5 minutes ago查不到日志,不是日志丢了,而是你机器上的时间和实际时间差了几个小时,在你眼里“最近五分钟”对应的其实是一段没有日志的“未来时段”。3. journald 存储配置:从临时到持久、从无限制到可控3.1 持久化存储配置与原因分析前面提到,Ubuntu 22.04 默认情况下如果/var/log/journal/不存在,journald 会把日志写到/run/log/journal/。 这意味着每次重启,之前的日志就没了。 对于桌面版或者临时测试机,这个行为还能接受;但对于服务器,这是不可接受的——你重启机器就是为了排查故障,结果重启后把故障现场日志给清掉了,这等于把破案线索给毁了。把日志改成持久化非常简单:sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald重启后 journald 检测到/var/log/journal/存在,就会自动把存储路径切换到持久化模式。 验证方法是用journalctl --disk-usage看存储位置,或者执行:journalctl --header | grep -i File path输出里能看到日志文件的具体路径,如果是/var/log/journal/...,说明已经持久化成功。3.2 journald 的磁盘占用上限设置journald 默认对日志占用的磁盘空间没有做一个严格的上限,日志会在系统盘里持续增长。 一个繁忙的 Web 服务器,journald 日志增长到几个 GB 是常态。 如果不限制,迟早会把磁盘占满,导致数据库或其他服务写入失败。限制方案是修改/etc/systemd/journald.conf:[Journal] SystemMaxUse500M MaxRetentionSec7daySystemMaxUse500M:journald 最多使用 500MB 磁盘空间;MaxRetentionSec7day:日志最多保留 7 天,更早的自动丢弃。改完记得重启:sudo systemctl restart systemd-journald实际项目里,日志量小但需要保留时间长的,比如安全审计类机器,可以把SystemMaxUse调大一些,比如 2G,把MaxRetentionSec设为30day;而日志量大但对历史查询要求不高的业务机器,反而应该调小SystemMaxUse,并且依赖集中日志平台做历史归档。 关键判断标准是:本地日志到底要不要承担“历史查询”的职责。3.3 journald 日志清空的正确姿势很多人问“journald 日志怎么清空”,我建议先说清楚两种场景,别一上来就journalctl --vacuum。如果你只是想腾出磁盘空间,但希望保留最近几天的日志,用:journalctl --vacuum-time3d这个命令会删除 3 天之前的日志,但保留最近的。 同理,想按日志量清理,用:journalctl --vacuum-size200M想彻底清空,用:sudo journalctl --rotate sudo journalctl --vacuum-time1s但注意,彻底清空是幂等性很差的操作,请确认你已经不需要这些日志。 通常我建议先journalctl --disk-usage看一下当前占用,再决定执行哪种清理策略,而不是无脑全清。3.4 把 journald 日志转发给 rsyslog 落盘尽管 journald 很强大,但很多已有的日志分析工具还是习惯读文本文件。 如果你希望/var/log/syslog能持续收到 journald 里全部日志,可以打开 journald.conf 里的转发开关:[Journal] ForwardToSyslogyes默认情况下这个选项就已经是yes,如果没有,改完后重启 journald。 转发开启后,rsyslog 会持续接收 journald 投递过来的消息,再按/etc/rsyslog.d/50-default.conf里的规则分发到各个文件。这里顺带提一个问题:有些人在/var/log/里找不到某个服务的日志,就以为系统没记录。 实际上,如果服务不是通过 syslog 接口写日志,而是只往 stdout 输出,那么这些日志只存在于 journald,不会出现在/var/log/syslog里。 这时你要在 rsyslog 配置里加上一条规则,把该服务的日志单独落盘:cat /etc/rsyslog.d/myservice.conf EOF :programname, isequal, myservice /var/log/myservice.log stop EOF systemctl restart rsyslog这条规则的意图是:凡是程序名等于myservice的日志,写入/var/log/myservice.log,并且不再继续走后面的默认规则,避免重复写入。4. 文件型日志的轮转、清空与远程采集4.1 logrotate 轮转机制与配置/var/log/下的文本文件如果不做轮转,单文件会越涨越大,大到一定程度grep都很吃力。 Ubuntu 22.04 自带logrotate的每日定时任务,配置文件在/etc/logrotate.conf,各种服务的轮转规则在/etc/logrotate.d/下。看一个典型配置:/var/log/myservice.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }逐个解释:daily:每天轮转一次;rotate 7:保留最近 7 个轮转后的文件;compress:旧日志压缩成 gz 格式;delaycompress:压缩延迟一次,也就是最新轮转出来的那个文件先不压缩,方便偶尔还需要直接查看;missingok:文件不存在不报错;notifempty:文件为空不执行轮转;copytruncate:先复制文件内容再清空原文件。 这个选项对有进程持续写入的文件很关键,避免了因为移动文件导致进程句柄失效的问题。配置完可以用sudo logrotate -d /etc/logrotate.conf做一次调试,-d是 dry-run,不会真正执行,只打印要做的动作,确保规则没有语法错误。4.2 清空大日志文件的三种安全方式线上服务器最容易出现的场景是:某个日志文件已经几百 MB,但你不想删除它,因为进程还开着文件句柄。 如果直接rm掉,进程还会继续向这个已被删除的 inode 写入,磁盘空间不会被释放。 正确的做法是清空文件内容而不是删除文件。第一种方式: /var/log/syslog这种方式用重定向把文件截断为空,但文件本身还在,进程句柄不受影响。 这在 bash 里是最常用的。第二种方式:truncate -s 0 /var/log/syslog这种方式效果和重定向一样,好处是可以指定截断到特定大小,比如truncate -s 100M把文件截断到 100MB,适合你想保留最后一部分内容的情况。第三种方式:使用logrotate的copytruncate机制,在轮转的同时清空原文件,这适合需要“保留历史 腾出磁盘空间”并存的场景。我个人的建议是:日常手动清空用第一种,简单可靠;自动化场景用 logrotate;至于直接rm日志文件,除非你明确知道进程会重新创建文件,否则不推荐。4.3 filebeat 日志采集部署参考当服务器数量多了,日志的价值就体现在“汇总分析”而非“单机查看”。 ELK 或 Loki 这类方案通常需要一个采集端代理,filebeat是用户量最大、配置门槛最低的之一。Ubuntu 22.04 上部署 filebeat 的流程大概是:先添加 Elastic 官方源、安装 filebeat,然后修改/etc/filebeat/filebeat.yml,定义采集路径和输出目标。 一个最简配置示例:filebeat.inputs: - type: filestream id: syslog paths: - /var/log/syslog output.logstash: hosts: [192.168.1.100:5044]这里用filestream类型是因为新版 filebeat 推荐用它替代旧的log类型,它对文件轮转和多行日志的支持更完善。 改完配置后用filebeat test output验证连通性,再systemctl start filebeat启动采集。有一个高频问题:filebeat 启动了但采集端没收到数据,先查这两个地方——一是filebeat test input确认能不能读到文件内容,二是journalctl -u filebeat看采集器自身的日志有没有报错。 采集器自身的日志是定位一切问题的起点。4.4 无日志文件夹或日志不落盘的排查思路有人会遇到“日志文件夹都不存在”的情况,比如/var/log/nginx/下是空的,或者/var/log/journal/不存在。 针对这两种情况,排查思路完全不同。/var/log/journal/不存在属于前文提到的持久化未开启,直接用mkdir restart journald解决。/var/log/nginx/下没日志,先看 nginx 的配置里access_log和error_log指令到底写到了哪个路径。 有的发行版把路径写成了/var/log/nginx/access.log,但 nginx 进程是 nobody 用户,对那个目录没有写权限,日志自然就不会产生。 这时需要确认目录权限,或者把日志路径改到有权限的地方。更深一层的问题是:应用根本没往日志里写东西。 比如某些服务把日志全部输出到 stdout,在 systemd 服务里看不到日志文件,但 journald 里是有的。 这时候你应该journalctl -u 应用名去看,而不是执着于找日志文件。 这个认知转换,在 22.04 这种系统下格外重要。5. 典型场景一网打尽:慢查询、内核日志与升级前后对比5.1 慢查询日志怎么定位和启用“慢查询日志”这个词在不同场景下含义不同。 数据库场景的单说,系统排障场景里慢查询更接近 DTrace、perf 这类性能追踪工具的输出。 Ubuntu 22.04 自带systemd-analyze可以分析开机过程中的慢环节:systemd-analyze blame这条命令会列出每个服务启动所花的时间,按从长到短排序。 比如某个服务花了 30 秒才启动完,blame一下基本就能定位到。 还可以配合systemd-analyze critical-chain看关键启动链路,找出拖慢整个开机流程的瓶颈服务。如果要排查运行中的进程慢在哪,惯用方式是perf top或perf record -g。 这两个工具需要先安装:sudo apt install linux-tools-common linux-tools-generic需要注意:某些云内核或低版本内核可能不支持 perf 的部分能力,安装完先跑perf top看有没有输出,没输出就查内核模块加载情况。5.2 dmesg 与内核日志的正确打开方式内核日志的查看命令是dmesg,但 Ubuntu 22.04 上直接跑dmesg有权限限制,非 root 用户会看到Operation not permitted。 解决方式是sudo dmesg或者把用户加入adm组,一般 Ubuntu 桌面版安装时创建的第一个用户就在adm和sudo组里,所以直接sudo dmesg即可。dmesg -T可以把时间戳显示成人类可读格式,配合dmesg -w可以实时跟踪内核日志输出。 排查 USB 设备、网卡驱动问题时,dmesg几乎是无冕之王。 比如“Ubuntu 22.04 识别不对有线网卡”这类问题,第一步永远是插上网线后执行:dmesg | grep -i eth dmesg | grep -i link链路不 UP、驱动没加载、固件缺失,都能在这两条命令的输出里看到端倪。 内核日志同样可以在/var/log/kern.log里查到,但dmesg的实时性更强,适合排查动态硬件事件。5.3 系统升级前后的日志对比策略升级前拍快照这个操作很多人只在虚拟机层面做,但在日志层面同样值得做。 我强烈建议,在apt upgrade之前先备份关键日志:sudo cp -a /var/log /var/log.bak.$(date %Y%m%d)注意用cp -a保留权限和时间属性,这样后续比对时不会因为文件权限不同而产生干扰。升级完成后,如果系统出现新问题,优先查三个时间节点:upgrade 开始时间、最后一次重启时间、问题首次出现时间。 用 journald 的--since参数把这三个节点附近的日志分别拉出来:journalctl --since 2025-01-20 10:00:00 --until 2025-01-20 10:30:00 -p warning通过对比升级前后同一时间段内的日志级别分布,往往能很快发现是哪个服务在升级后开始报错。 我自己遇到过很多次:某个库版本升级导致应用依赖冲突,日志里没有直接报“依赖冲突”,而是相关的服务不断重启、拒绝连接。 不看日志,你可能会去怀疑网络或者防火墙,但一打开 journald,Unit xxx.service entered failed state这条日志就会直接告诉你答案。5.4 日志轮转与过大的 SQL Server 日志类比热词里有“sql2008日志文件过大怎么删除”“binlog日志可以删除吗”,这些跟 Ubuntu 22.04 虽不是同一场景,但处理逻辑是相通的:任何日志系统都要有配额上限、保留周期和手动清理手段。 对文件型日志,用 logrotate;对 journald 二进制日志,用journalctl --vacuum-size/--vacuum-time;对数据库日志,用数据库自带的清理命令。 思路一致:先确认谁能安全删除,再决定怎么删,而不是盲目地rm。Binlog 这类用于主从复制的日志,更不能随手删——删错了可能导致从库无法追平主库。 同样地,系统里有些日志跟安全审计相关,比如auth.log,清理之前要考虑合规要求。 总而言之,日志处理的第一原则不是“删得快”,而是“删得对”。6. 常见问题与排查技巧实录6.1 journalctl 查不到服务日志这是我被问得最多的问题之一。journalctl -u nginx.service输出为空,但 nginx 明明在跑。 遇到这种情况,先确认服务是不是 systemd 托管的。 如果 nginx 是用docker跑的,那它根本不在 host 的 systemd 单元列表里,-u自然查不到。 正确排查方式是用docker logs 容器名。如果确实是 systemd 服务,再确认服务名是否写对。systemctl list-units --typeservice | grep nginx先看一眼准确名称。 另外注意 nginx 的 master 进程和 worker 进程的日志单元归属可能不同,有时候-u nginx查不到,但journalctl _COMMnginx能查到。6.2 日志时间显示成 UTC 怎么办这一节前文讲过,这里补充一个容易忽略的点:journalctl显示的时间默认是本地时间,但如果你的系统时区没设置好,它可能显示 UTC。 修改时区后 journald 的时间戳会变,但已经写入的日志时间不会自动换算,而是按原内核时间戳原样展示。 所以时区配置一定要尽早完成,最好在系统初始化阶段就设置好,不要等到日志积累了很多之后再来改。6.3 磁盘被日志占满,最紧急的处理顺序如果df -h显示/var或根分区使用率 100%,而且确认是日志导致的,紧急处理顺序应该是这样的:先看journald占了多少:journalctl --disk-usage;用journalctl --vacuum-size200M把 journald 缩小到 200M;再找/var/log下的大文件:du -ah /var/log | sort -rh | head -20;对最大的几个文件执行 文件路径截断,注意保留进程句柄;检查/var/log/journal/是否存在,如果不存在,顺手做掉持久化配置,避免重启后日志消失。这套顺序的核心思路是:先用占用小的手段journald 清理快速释放空间,再处理占用大的文本文件,整个过程不会因为误删导致服务崩溃。 切忌一上来就rm -rf /var/log/*,这种操作会让正在运行的进程失去日志通道,后续排查问题时你将一无所有。6.4 filebeat 配置文件常见坑再补一个 filebeat 的坑:采集/var/log/syslog后,输出端没收到数据,但filebeat test output显示连接正常。 这时候大概率是采集路径的权限问题。 filebeat 进程以 root 之外的用户运行时,对/var/log/syslog可能没有读权限。 解决办法是给 filebeat 指定root用户:service: user: root或者在 filebeat 配置里以 root 方式启动服务。 因为安全考虑,默认的 filebeat 服务会降权运行,而系统日志文件的权限通常只允许 root 和 adm 组读取,所以采集系统日志的 filebeat 必须显式以 root 身份运行。 这个细节,文档里写得不显眼,但几乎人人都会踩一次。6.5 桌面用户遇到的问题:U盘、上传文件与日志的间接关系有热词提到“Ubuntu 22.04 桌面版怎么上传文件,能插上 U 盘读取吗”,这虽然看起来和日志没关系,但排障思路是相通的。 桌面版插 U 盘后识别不到,第一反应应该是看内核日志:dmesg -T | grep -i usb dmesg -T | grep -i sd如果插上 U 盘后dmesg里出现了sdb之类的设备节点,那就是文件系统挂载层面的问题,查桌面环境的磁盘工具即可;如果dmesg里完全没有新设备出现,那就要检查 USB 口、驱动和 BIOS 设置。 这类硬件问题如果没有日志,基本就是瞎子摸象,所以日志处理能力其实是所有系统调试问题的基础能力。7. 日志视图与作用域:理清“谁在记、记到哪、谁能看”7.1 日志作用域的理解journald 把日志按来源分成了多种字段,常见的有_SYSTEMD_UNIT服务单元、_COMM进程名、_PID进程号、_HOSTNAME主机名。 这些字段构成了日志的作用域:你可以按任意一个维度切分日志,而不必被文件路径绑定。比如我想看某个进程启动后所有跟它有关的日志,可以:journalctl _COMMpython3 --since today想精确到 PID,防止同名进程混淆:journalctl _PID12345这种基于字段的过滤,是文本日志时代很难实现的。 这也是为什么我建议运维同事尽快习惯 journald 的查询方式,而不是守着/var/log/syslog不放。7.2 多个服务共用一个日志文件时的区分在一些老旧系统上,多个服务都往syslog里写,日志混在一起很难看。 但是 journald 里不同服务的日志天然按_SYSTEMD_UNIT区分,所以你可以先journalctl -u serviceA,再journalctl -u serviceB,分开查。如果必须合并查看并按时间对齐,可以用:journalctl -u serviceA -u serviceB --since today多个-u参数会合并不同单元的日志,并按时间排序输出。 这种方式比cat /var/log/syslog | grep serviceA要干净利落得多,而且还能保留时间戳的精确顺序。7.3 如何按用户维度查看日志如果你接管了一台多人共用的服务器,想查某个特定用户的登录历史和操作记录,可以使用:journalctl _UID1000 --since today这个_UID字段是 journald 根据进程运行时的 UID 自动写入的,不需要应用层面额外支持。 再配合grep可以快速梳理该用户今天的操作轨迹。 这在排查“某个普通用户执行了什么导致系统异常”时非常有用。实操经验总结与个人建议把 Ubuntu 22.04 的日志处理做完一轮之后,我最深的体会是:日志这种东西,平时你觉得它占地方,真要出问题的时候,它就是唯一的证据链。 所以尽早把持久化、配额、轮转这三件事配好,比任何高级技巧都重要。 我个人强烈建议每台 Ubuntu 22.04 服务器在初始化时就执行下面这套“日志三板斧”:一是创建/var/log/journal并重启 journald,确保持久化;二是修改/etc/systemd/journald.conf设置大小上限和保留周期;三是确认 logrotate 定时任务正常 enabled。 三件事做完,你能少掉一半的日志类故障。再分享一个小技巧:不管是看系统日志还是应用日志,先看时间戳和主机名,再看内容。 很多人排查问题失败,不是因为没看到日志,而是因为拿错机器的时间在判断,或者把不同主机的日志混在一起当成同一台机器的输出。 加个-H参数或者让 shell 在终端标题栏显示当前主机名,可以显著减少这类低级失误。日志处理这个事,没有一招鲜,但底层逻辑就一条:知道日志从哪里来、存到哪里去、保留多久、怎么查最快。 把这条链路想明白,无论日志以什么形式出现,你都能顺着摸到根源。 Ubuntu 22.04 日志体系详解：journalctl、持久化与轮转清理实践
干运维和开发这些年,Ubuntu 22.04 是我用得最久的 LTS 版本之一。 系统跑得越久,日志就越像个杂物间——你以为没用的东西堆了一地,可真要排查问题的时候,又翻不着关键的那一条。 这篇文章不聊虚的,直接讲透 Ubuntu 22.04 日志体系的底层逻辑,再把查看、清理、持久化、采集这些实操动作一个个拆开给你看。 不管你是刚接触服务器的初学者,还是已经被线上问题折腾过几轮的同行,这篇都能让你少走弯路。我先说一个很多人踩过的坑:以为日志就是/var/log下那一堆syslog、auth.log,然后tail -f里盯着看。 实际上 Ubuntu 22.04 引入了 systemd 之后,日志的主战场早就换到了 journald,/var/log里的文件更多是 rsyslog 从 journald 那边“接货”之后再落盘的产物。 如果搞不清这条链路,你会遇到两种典型症状:一种是journalctl里看不到东西,另一种是/var/log/syslog半天不更新,然后你开始怀疑是不是日志丢了。 其实都没丢,只是你站错了观察点。1. Ubuntu 22.04 日志体系与整体处理思路1.1 两条日志管线的分工逻辑Ubuntu 22.04 默认同时跑着两套日志收集系统,可以理解为一家公司里“前台接待”和“档案室”的关系。前台接待就是systemd-journald,它负责把内核日志、系统服务日志、各进程通过标准输出stdout/stderr打出来的信息全部接住,统一写进自己的二进制日志里。 这个二进制日志的存储路径默认在/var/log/journal/,不过 22.04 有个细节:如果这个目录不存在,日志会暂时落在/run/log/journal/,而/run是内存文件系统,重启就没了。 很多人在虚拟机上装好 22.04,跑了两天突然发现journalctl --since today能看到的东西变少,或者重启后查不到之前的开机日志,多半就是这个原因。档案室就是rsyslog,它从 journald 那边接收消息,然后按照配置把日志分门别类写入文本文件,比如auth.log、kern.log、syslog等。 它的配置在/etc/rsyslog.conf和/etc/rsyslog.d/下,默认规则已经分得很好,一般不用动。理解这条链路的意义在于:你在排查问题时,journalctl是获取原始日志的权威入口,而/var/log/下的文本文件是经过 rsyslog“加工”后的产物。 如果两边内容对不上,优先检查 journald 的配额有没有被写满、journald 是否处于持久化模式、rsyslog 服务是否还在正常运行。1.2 为什么选择 journald 作为核心很多人刚接触 journald 时觉得不适应,因为它的日志是二进制格式,不能直接cat,必须用journalctl来读。 但从工程角度看,这个设计是划算的——二进制存储带来了三个实在的好处:一是启动过程的早期日志也能被精准记录,不会因为服务依赖顺序而丢日志;二是可以用结构化字段做过滤,比如按服务名、PID、优先级、可执行文件路径来筛,这种维度是纯文本日志很难实现的;三是日志自带时间戳、主机名和单元信息,查问题时不用再靠肉眼去猜一条日志来自哪里。我在实际排障中有一个习惯:先journalctl -u 服务名 --since 10 minutes ago快速锁定服务状态变化,再去翻/var/log/syslog找上下游的联动痕迹。 这样的排查路径比直接开文件快得多。1.3 明确日志处理的目标场景日志处理不是一个单一动作,而是对应几种典型目标:问题追踪:某服务突然挂了,需要从日志里还原崩溃前的调用序列;安全审计:查看登录记录、sudo 操作记录,确认是否有异常 IP 尝试登录;容量控制:日志无限增长导致磁盘爆满,需要做轮转和清理;集中采集:多台服务器的日志要汇总到统一的日志平台如 ELK、Loki,便于集中检索和告警。不同目标对应的处理动作不一样。 如果只是临时排查,命令级别的操作就足够;如果要长期运维,就必须做 journald 配额限制、logrotate 轮转策略、乃至日志采集代理的部署。 这篇文章会按这条路径一步步展开。2. 查看日志:journalctl 与经典日志文件的实操要点2.1 journalctl 的高效用法journalctl是处理 journald 日志的唯一入口,但它的参数非常多,很多新手记不住。 我平时真正高频使用的就那几个组合,可以分三层来说。第一层是时间维度的过滤。 比如查昨天的日志,用journalctl --since yesterday;查最近五分钟,用journalctl --since 5 minutes ago;查固定时间区间,用journalctl --since 2024-06-01 10:00:00 --until 2024-06-01 12:00:00。 时间的写法很灵活,支持today、yesterday、tomorrow,也支持-1 hour这类相对时间。 我强烈建议你把时间过滤当成肌肉记忆,因为生产环境日志量大的时候,不带时间参数直接journalctl,输出会大到让你怀疑人生。第二层是单元维度的过滤。 查某个服务的日志,用journalctl -u ssh.service;查某个服务的最近日志并持续跟踪,用journalctl -u nginx.service -f。 这比去/var/log/nginx/error.log翻文件更全,因为 journald 会把服务启动早期、进程 stdout 输出的内容全都收纳进来,而应用自身的日志文件往往只记录了应用认为“值得记录”的内容。第三层是优先级过滤。 日志级别从上到下是emerg、alert、crit、err、warning、notice、info、debug,用journalctl -p err就能只看错误及以上级别的日志。 这里有个小技巧:-p err实际上是“err 及以上”,也就是会把 crit、alert、emerg 也带出来。 排查问题时先journalctl -p err -since today,如果没发现,再放宽到warning,这种“从高往低放宽”的顺序能帮你快速定位异常。2.2 经典日志文件怎么配合着看虽然 journald 更强,但有些场景下文本日志依然不可替代。 比如sudo的所有执行记录只会出现在/var/log/auth.log里,journalctl | grep sudo虽然也能找到,但效率和准确性都不如直接查auth.log。Ubuntu 22.04 下值得关注的日志文件主要有这几个:/var/log/syslog:系统全局日志,几乎所有经过 rsyslog 的消息都会汇总在这里;/var/log/auth.log:认证与授权日志,登录、sudo、SSH 密钥校验都在这里;/var/log/kern.log:内核日志,硬件问题、驱动报错通常在这里;/var/log/dpkg.log:软件包管理日志,apt install和dpkg的痕迹都在这;/var/log/boot.log:开机启动过程的日志。我在排查 SSH 登录问题时有个固定动作:先grep Failed password /var/log/auth.log,统计失败次数和来源 IP,再配合journalctl -u ssh --since today看完整的连接过程。 前者适合做安全审计,后者适合做问题溯源,两个视角互相补充。2.3 日志量太大时先做什么日志量大的时候,最忌讳的就是直接cat整个文件。 我见过有人对几百兆的syslog执行cat,结果终端卡死,不得不强制重开会话。 正确的顺序一定是“时间过滤 关键词过滤 翻页查看”三件套,比如这样:journalctl --since 30 minutes ago | grep -i error | less如果觉得每次敲一长串命令太麻烦,可以给常用的查询做别名,放进~/.bashrc:alias jerrjournalctl -p err --since today alias jserjournalctl -u sshd --since today alias jalljournalctl --since 10 minutes ago这样每次排查的时候只需要输入两三个字母就能开始,效率提升非常明显。2.4 查看 crontab 执行日志的方法这个需求在热词里出现频率很高。 Ubuntu 22.04 里 cron 的实际执行日志默认走 rsyslog,会写进/var/log/syslog,可以用grep CRON /var/log/syslog来看。 但生产环境 syslog 经常轮转得很快,很多时候你想查的那几条已经被轮转掉了。更可靠的方式是检查 cron 任务自身有没有把输出重定向到文件。 比如你的 crontab 里写的是0 2 * * * /opt/backup.sh,那脚本的标准输出默认会被 cron 吞掉。 想追踪执行情况,最稳妥的做法是改成这样:0 2 * * * /opt/backup.sh /var/log/backup.log 21同时在脚本里加执行时间戳:echo $(date %Y-%m-%d %H:%M:%S) backup start /var/log/backup.log这样一来,任务的执行记录就不依赖系统日志轮转了,任何时候都能回溯。 我在实际运维中,凡是新建 cron 任务,第一件事就是确认输出有没有落到固定文件,这一步能省掉后续大量的排查时间。2.5 日志时间不对怎么处理Ubuntu 22.04 默认使用 UTC 时间,如果你的服务器时区设置不对,会发现日志时间和你本地时间对不上。 处理方式很简单:sudo timedatectl set-timezone Asia/Shanghai执行完可以date验证一下。 注意 journald 对时区变化是敏感的,改完时区后最好重启一次 journald 让时间戳刷新:sudo systemctl restart systemd-journald这里要提醒一点:千万不要把时区问题和日志丢失混为一谈。 有时你用journalctl --since 5 minutes ago查不到日志,不是日志丢了,而是你机器上的时间和实际时间差了几个小时,在你眼里“最近五分钟”对应的其实是一段没有日志的“未来时段”。3. journald 存储配置:从临时到持久、从无限制到可控3.1 持久化存储配置与原因分析前面提到,Ubuntu 22.04 默认情况下如果/var/log/journal/不存在,journald 会把日志写到/run/log/journal/。 这意味着每次重启,之前的日志就没了。 对于桌面版或者临时测试机,这个行为还能接受;但对于服务器,这是不可接受的——你重启机器就是为了排查故障,结果重启后把故障现场日志给清掉了,这等于把破案线索给毁了。把日志改成持久化非常简单:sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald重启后 journald 检测到/var/log/journal/存在,就会自动把存储路径切换到持久化模式。 验证方法是用journalctl --disk-usage看存储位置,或者执行:journalctl --header | grep -i File path输出里能看到日志文件的具体路径,如果是/var/log/journal/...,说明已经持久化成功。3.2 journald 的磁盘占用上限设置journald 默认对日志占用的磁盘空间没有做一个严格的上限,日志会在系统盘里持续增长。 一个繁忙的 Web 服务器,journald 日志增长到几个 GB 是常态。 如果不限制,迟早会把磁盘占满,导致数据库或其他服务写入失败。限制方案是修改/etc/systemd/journald.conf:[Journal] SystemMaxUse500M MaxRetentionSec7daySystemMaxUse500M:journald 最多使用 500MB 磁盘空间;MaxRetentionSec7day:日志最多保留 7 天,更早的自动丢弃。改完记得重启:sudo systemctl restart systemd-journald实际项目里,日志量小但需要保留时间长的,比如安全审计类机器,可以把SystemMaxUse调大一些,比如 2G,把MaxRetentionSec设为30day;而日志量大但对历史查询要求不高的业务机器,反而应该调小SystemMaxUse,并且依赖集中日志平台做历史归档。 关键判断标准是:本地日志到底要不要承担“历史查询”的职责。3.3 journald 日志清空的正确姿势很多人问“journald 日志怎么清空”,我建议先说清楚两种场景,别一上来就journalctl --vacuum。如果你只是想腾出磁盘空间,但希望保留最近几天的日志,用:journalctl --vacuum-time3d这个命令会删除 3 天之前的日志,但保留最近的。 同理,想按日志量清理,用:journalctl --vacuum-size200M想彻底清空,用:sudo journalctl --rotate sudo journalctl --vacuum-time1s但注意,彻底清空是幂等性很差的操作,请确认你已经不需要这些日志。 通常我建议先journalctl --disk-usage看一下当前占用,再决定执行哪种清理策略,而不是无脑全清。3.4 把 journald 日志转发给 rsyslog 落盘尽管 journald 很强大,但很多已有的日志分析工具还是习惯读文本文件。 如果你希望/var/log/syslog能持续收到 journald 里全部日志,可以打开 journald.conf 里的转发开关:[Journal] ForwardToSyslogyes默认情况下这个选项就已经是yes,如果没有,改完后重启 journald。 转发开启后,rsyslog 会持续接收 journald 投递过来的消息,再按/etc/rsyslog.d/50-default.conf里的规则分发到各个文件。这里顺带提一个问题:有些人在/var/log/里找不到某个服务的日志,就以为系统没记录。 实际上,如果服务不是通过 syslog 接口写日志,而是只往 stdout 输出,那么这些日志只存在于 journald,不会出现在/var/log/syslog里。 这时你要在 rsyslog 配置里加上一条规则,把该服务的日志单独落盘:cat /etc/rsyslog.d/myservice.conf EOF :programname, isequal, myservice /var/log/myservice.log stop EOF systemctl restart rsyslog这条规则的意图是:凡是程序名等于myservice的日志,写入/var/log/myservice.log,并且不再继续走后面的默认规则,避免重复写入。4. 文件型日志的轮转、清空与远程采集4.1 logrotate 轮转机制与配置/var/log/下的文本文件如果不做轮转,单文件会越涨越大,大到一定程度grep都很吃力。 Ubuntu 22.04 自带logrotate的每日定时任务,配置文件在/etc/logrotate.conf,各种服务的轮转规则在/etc/logrotate.d/下。看一个典型配置:/var/log/myservice.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }逐个解释:daily:每天轮转一次;rotate 7:保留最近 7 个轮转后的文件;compress:旧日志压缩成 gz 格式;delaycompress:压缩延迟一次,也就是最新轮转出来的那个文件先不压缩,方便偶尔还需要直接查看;missingok:文件不存在不报错;notifempty:文件为空不执行轮转;copytruncate:先复制文件内容再清空原文件。 这个选项对有进程持续写入的文件很关键,避免了因为移动文件导致进程句柄失效的问题。配置完可以用sudo logrotate -d /etc/logrotate.conf做一次调试,-d是 dry-run,不会真正执行,只打印要做的动作,确保规则没有语法错误。4.2 清空大日志文件的三种安全方式线上服务器最容易出现的场景是:某个日志文件已经几百 MB,但你不想删除它,因为进程还开着文件句柄。 如果直接rm掉,进程还会继续向这个已被删除的 inode 写入,磁盘空间不会被释放。 正确的做法是清空文件内容而不是删除文件。第一种方式: /var/log/syslog这种方式用重定向把文件截断为空,但文件本身还在,进程句柄不受影响。 这在 bash 里是最常用的。第二种方式:truncate -s 0 /var/log/syslog这种方式效果和重定向一样,好处是可以指定截断到特定大小,比如truncate -s 100M把文件截断到 100MB,适合你想保留最后一部分内容的情况。第三种方式:使用logrotate的copytruncate机制,在轮转的同时清空原文件,这适合需要“保留历史 腾出磁盘空间”并存的场景。我个人的建议是:日常手动清空用第一种,简单可靠;自动化场景用 logrotate;至于直接rm日志文件,除非你明确知道进程会重新创建文件,否则不推荐。4.3 filebeat 日志采集部署参考当服务器数量多了,日志的价值就体现在“汇总分析”而非“单机查看”。 ELK 或 Loki 这类方案通常需要一个采集端代理,filebeat是用户量最大、配置门槛最低的之一。Ubuntu 22.04 上部署 filebeat 的流程大概是:先添加 Elastic 官方源、安装 filebeat,然后修改/etc/filebeat/filebeat.yml,定义采集路径和输出目标。 一个最简配置示例:filebeat.inputs: - type: filestream id: syslog paths: - /var/log/syslog output.logstash: hosts: [192.168.1.100:5044]这里用filestream类型是因为新版 filebeat 推荐用它替代旧的log类型,它对文件轮转和多行日志的支持更完善。 改完配置后用filebeat test output验证连通性,再systemctl start filebeat启动采集。有一个高频问题:filebeat 启动了但采集端没收到数据,先查这两个地方——一是filebeat test input确认能不能读到文件内容,二是journalctl -u filebeat看采集器自身的日志有没有报错。 采集器自身的日志是定位一切问题的起点。4.4 无日志文件夹或日志不落盘的排查思路有人会遇到“日志文件夹都不存在”的情况,比如/var/log/nginx/下是空的,或者/var/log/journal/不存在。 针对这两种情况,排查思路完全不同。/var/log/journal/不存在属于前文提到的持久化未开启,直接用mkdir restart journald解决。/var/log/nginx/下没日志,先看 nginx 的配置里access_log和error_log指令到底写到了哪个路径。 有的发行版把路径写成了/var/log/nginx/access.log,但 nginx 进程是 nobody 用户,对那个目录没有写权限,日志自然就不会产生。 这时需要确认目录权限,或者把日志路径改到有权限的地方。更深一层的问题是:应用根本没往日志里写东西。 比如某些服务把日志全部输出到 stdout,在 systemd 服务里看不到日志文件,但 journald 里是有的。 这时候你应该journalctl -u 应用名去看,而不是执着于找日志文件。 这个认知转换,在 22.04 这种系统下格外重要。5. 典型场景一网打尽:慢查询、内核日志与升级前后对比5.1 慢查询日志怎么定位和启用“慢查询日志”这个词在不同场景下含义不同。 数据库场景的单说,系统排障场景里慢查询更接近 DTrace、perf 这类性能追踪工具的输出。 Ubuntu 22.04 自带systemd-analyze可以分析开机过程中的慢环节:systemd-analyze blame这条命令会列出每个服务启动所花的时间,按从长到短排序。 比如某个服务花了 30 秒才启动完,blame一下基本就能定位到。 还可以配合systemd-analyze critical-chain看关键启动链路,找出拖慢整个开机流程的瓶颈服务。如果要排查运行中的进程慢在哪,惯用方式是perf top或perf record -g。 这两个工具需要先安装:sudo apt install linux-tools-common linux-tools-generic需要注意:某些云内核或低版本内核可能不支持 perf 的部分能力,安装完先跑perf top看有没有输出,没输出就查内核模块加载情况。5.2 dmesg 与内核日志的正确打开方式内核日志的查看命令是dmesg,但 Ubuntu 22.04 上直接跑dmesg有权限限制,非 root 用户会看到Operation not permitted。 解决方式是sudo dmesg或者把用户加入adm组,一般 Ubuntu 桌面版安装时创建的第一个用户就在adm和sudo组里,所以直接sudo dmesg即可。dmesg -T可以把时间戳显示成人类可读格式,配合dmesg -w可以实时跟踪内核日志输出。 排查 USB 设备、网卡驱动问题时,dmesg几乎是无冕之王。 比如“Ubuntu 22.04 识别不对有线网卡”这类问题,第一步永远是插上网线后执行:dmesg | grep -i eth dmesg | grep -i link链路不 UP、驱动没加载、固件缺失,都能在这两条命令的输出里看到端倪。 内核日志同样可以在/var/log/kern.log里查到,但dmesg的实时性更强,适合排查动态硬件事件。5.3 系统升级前后的日志对比策略升级前拍快照这个操作很多人只在虚拟机层面做,但在日志层面同样值得做。 我强烈建议,在apt upgrade之前先备份关键日志:sudo cp -a /var/log /var/log.bak.$(date %Y%m%d)注意用cp -a保留权限和时间属性,这样后续比对时不会因为文件权限不同而产生干扰。升级完成后,如果系统出现新问题,优先查三个时间节点:upgrade 开始时间、最后一次重启时间、问题首次出现时间。 用 journald 的--since参数把这三个节点附近的日志分别拉出来:journalctl --since 2025-01-20 10:00:00 --until 2025-01-20 10:30:00 -p warning通过对比升级前后同一时间段内的日志级别分布,往往能很快发现是哪个服务在升级后开始报错。 我自己遇到过很多次:某个库版本升级导致应用依赖冲突,日志里没有直接报“依赖冲突”,而是相关的服务不断重启、拒绝连接。 不看日志,你可能会去怀疑网络或者防火墙,但一打开 journald,Unit xxx.service entered failed state这条日志就会直接告诉你答案。5.4 日志轮转与过大的 SQL Server 日志类比热词里有“sql2008日志文件过大怎么删除”“binlog日志可以删除吗”,这些跟 Ubuntu 22.04 虽不是同一场景,但处理逻辑是相通的:任何日志系统都要有配额上限、保留周期和手动清理手段。 对文件型日志,用 logrotate;对 journald 二进制日志,用journalctl --vacuum-size/--vacuum-time;对数据库日志,用数据库自带的清理命令。 思路一致:先确认谁能安全删除,再决定怎么删,而不是盲目地rm。Binlog 这类用于主从复制的日志,更不能随手删——删错了可能导致从库无法追平主库。 同样地,系统里有些日志跟安全审计相关,比如auth.log,清理之前要考虑合规要求。 总而言之,日志处理的第一原则不是“删得快”,而是“删得对”。6. 常见问题与排查技巧实录6.1 journalctl 查不到服务日志这是我被问得最多的问题之一。journalctl -u nginx.service输出为空,但 nginx 明明在跑。 遇到这种情况,先确认服务是不是 systemd 托管的。 如果 nginx 是用docker跑的,那它根本不在 host 的 systemd 单元列表里,-u自然查不到。 正确排查方式是用docker logs 容器名。如果确实是 systemd 服务,再确认服务名是否写对。systemctl list-units --typeservice | grep nginx先看一眼准确名称。 另外注意 nginx 的 master 进程和 worker 进程的日志单元归属可能不同,有时候-u nginx查不到,但journalctl _COMMnginx能查到。6.2 日志时间显示成 UTC 怎么办这一节前文讲过,这里补充一个容易忽略的点:journalctl显示的时间默认是本地时间,但如果你的系统时区没设置好,它可能显示 UTC。 修改时区后 journald 的时间戳会变,但已经写入的日志时间不会自动换算,而是按原内核时间戳原样展示。 所以时区配置一定要尽早完成,最好在系统初始化阶段就设置好,不要等到日志积累了很多之后再来改。6.3 磁盘被日志占满,最紧急的处理顺序如果df -h显示/var或根分区使用率 100%,而且确认是日志导致的,紧急处理顺序应该是这样的:先看journald占了多少:journalctl --disk-usage;用journalctl --vacuum-size200M把 journald 缩小到 200M;再找/var/log下的大文件:du -ah /var/log | sort -rh | head -20;对最大的几个文件执行 文件路径截断,注意保留进程句柄;检查/var/log/journal/是否存在,如果不存在,顺手做掉持久化配置,避免重启后日志消失。这套顺序的核心思路是:先用占用小的手段journald 清理快速释放空间,再处理占用大的文本文件,整个过程不会因为误删导致服务崩溃。 切忌一上来就rm -rf /var/log/*,这种操作会让正在运行的进程失去日志通道,后续排查问题时你将一无所有。6.4 filebeat 配置文件常见坑再补一个 filebeat 的坑:采集/var/log/syslog后,输出端没收到数据,但filebeat test output显示连接正常。 这时候大概率是采集路径的权限问题。 filebeat 进程以 root 之外的用户运行时,对/var/log/syslog可能没有读权限。 解决办法是给 filebeat 指定root用户:service: user: root或者在 filebeat 配置里以 root 方式启动服务。 因为安全考虑,默认的 filebeat 服务会降权运行,而系统日志文件的权限通常只允许 root 和 adm 组读取,所以采集系统日志的 filebeat 必须显式以 root 身份运行。 这个细节,文档里写得不显眼,但几乎人人都会踩一次。6.5 桌面用户遇到的问题:U盘、上传文件与日志的间接关系有热词提到“Ubuntu 22.04 桌面版怎么上传文件,能插上 U 盘读取吗”,这虽然看起来和日志没关系,但排障思路是相通的。 桌面版插 U 盘后识别不到,第一反应应该是看内核日志:dmesg -T | grep -i usb dmesg -T | grep -i sd如果插上 U 盘后dmesg里出现了sdb之类的设备节点,那就是文件系统挂载层面的问题,查桌面环境的磁盘工具即可;如果dmesg里完全没有新设备出现,那就要检查 USB 口、驱动和 BIOS 设置。 这类硬件问题如果没有日志,基本就是瞎子摸象,所以日志处理能力其实是所有系统调试问题的基础能力。7. 日志视图与作用域:理清“谁在记、记到哪、谁能看”7.1 日志作用域的理解journald 把日志按来源分成了多种字段,常见的有_SYSTEMD_UNIT服务单元、_COMM进程名、_PID进程号、_HOSTNAME主机名。 这些字段构成了日志的作用域:你可以按任意一个维度切分日志,而不必被文件路径绑定。比如我想看某个进程启动后所有跟它有关的日志,可以:journalctl _COMMpython3 --since today想精确到 PID,防止同名进程混淆:journalctl _PID12345这种基于字段的过滤,是文本日志时代很难实现的。 这也是为什么我建议运维同事尽快习惯 journald 的查询方式,而不是守着/var/log/syslog不放。7.2 多个服务共用一个日志文件时的区分在一些老旧系统上,多个服务都往syslog里写,日志混在一起很难看。 但是 journald 里不同服务的日志天然按_SYSTEMD_UNIT区分,所以你可以先journalctl -u serviceA,再journalctl -u serviceB,分开查。如果必须合并查看并按时间对齐,可以用:journalctl -u serviceA -u serviceB --since today多个-u参数会合并不同单元的日志,并按时间排序输出。 这种方式比cat /var/log/syslog | grep serviceA要干净利落得多,而且还能保留时间戳的精确顺序。7.3 如何按用户维度查看日志如果你接管了一台多人共用的服务器,想查某个特定用户的登录历史和操作记录,可以使用:journalctl _UID1000 --since today这个_UID字段是 journald 根据进程运行时的 UID 自动写入的,不需要应用层面额外支持。 再配合grep可以快速梳理该用户今天的操作轨迹。 这在排查“某个普通用户执行了什么导致系统异常”时非常有用。实操经验总结与个人建议把 Ubuntu 22.04 的日志处理做完一轮之后,我最深的体会是:日志这种东西,平时你觉得它占地方,真要出问题的时候,它就是唯一的证据链。 所以尽早把持久化、配额、轮转这三件事配好,比任何高级技巧都重要。 我个人强烈建议每台 Ubuntu 22.04 服务器在初始化时就执行下面这套“日志三板斧”:一是创建/var/log/journal并重启 journald,确保持久化;二是修改/etc/systemd/journald.conf设置大小上限和保留周期;三是确认 logrotate 定时任务正常 enabled。 三件事做完,你能少掉一半的日志类故障。再分享一个小技巧:不管是看系统日志还是应用日志,先看时间戳和主机名,再看内容。 很多人排查问题失败,不是因为没看到日志,而是因为拿错机器的时间在判断,或者把不同主机的日志混在一起当成同一台机器的输出。 加个-H参数或者让 shell 在终端标题栏显示当前主机名,可以显著减少这类低级失误。日志处理这个事,没有一招鲜,但底层逻辑就一条:知道日志从哪里来、存到哪里去、保留多久、怎么查最快。 把这条链路想明白,无论日志以什么形式出现,你都能顺着摸到根源。