排查服务异常那天，一直在纠结linux系统日志在哪里，网上随手点开的几句话看得我头都晕，一会说这个路径一会又指向别的地方，抱着试一试的心态去服务器里翻，结果来回折腾了快两个小时。
最先点开的是那个var下面的log文件夹，cd进去之后，密密麻麻一堆文件，名字看着都差不多，messages、secure、boot.log挤在一块。当时脑子想当然的觉得所有报错记录肯定全都堆在这里，直接拉取大文件，grep关键词来回跑命令，屏幕哗哗滚一堆文本，翻了好久，一条和我这次服务崩溃相关的记录都抓不到。
同事路过扫了一眼屏幕，只说了一句，看看是不是用journald管理日志。
那时候根本没搞懂journalctl和普通文本日志的区别，还固执的以为日志一定是存成可以直接cat读取的文件，继续在var/log里面来回切换文件，挨个打开瞧，有些日志文件还被切割成好几个，带数字后缀，分不清哪个是最新生成的，打开老日志看半天，全是几天前的旧信息，白白耗掉不少时间。服务器负载本来就偏高，反复读取大日志文件，ssh连接都卡了两下。
后来才反应过来，这台机器是新版的发行版，很多服务的日志不再持续写入静态文本文件，而是交给journal来维护，底层的二进制文件放在另一个目录，直接打开是乱码，没法像普通日志那样直接阅读。之前一直盯着var/log，等于从一开始就找错了重心。敲journalctl命令的时候，输出刷出来一大串，时间线是按时间倒序排列的，往下翻了一会，终于看见了服务崩溃那一瞬间打出的报错。
也不是说var/log里面就完全没有东西，像登录记录、开机过程的输出，依旧会留在那。只是不同机器的配置不一样，有的服务配置了输出到文件，有的直接交给系统日志服务托管，没有统一的存放位置。同一套排查命令，换到另外一台老版本服务器上，情况又不一样，那台机器就没有启用journal，所有记录老老实实落在文本里，journalctl查不到有效内容。
中间还踩过一个小坑，有些应用自己单独定义了日志输出路径，不走系统的这套，写在了程序目录底下的log文件夹里。那天的服务刚好是这样，一部分关键报错打到journal里，业务自身的详细堆栈单独存到应用目录，两边信息要拼在一起才能还原完整故障过程，只盯着系统日志的话，信息还是不全。
蹲在终端前面慢慢捋的时候，才慢慢意识到，这个问题本身没有一个唯一固定的答案。别人随口告诉你一个路径，换到你手上的机器，很可能就不适用。发行版版本、系统是否开启journal、应用自身的日志配置，每一项都会改变日志的存放位置。
折腾到傍晚，故障处理完，关掉ssh窗口的时候，眼睛还有点发酸。