服务器出问题的日志时候，第一反应不该是工具重启，而是日志看日志。这条经验值多少钱？工具我见过一个团队为了排查一个接口超时，折腾了整整两天，日志最后发现日志里早就写了"connection pool exhausted"，工具只是日志没人去看。

日志工具的工具核心价值就一个：让你在最短时间内找到那行要命的错误信息。围绕这个目标，日志工具的工具选择和使用方式才有讨论意义。

命令行派：快，日志但需要记性

tail -f 是工具最常用的起手式。实时盯着日志滚动，日志配合 grep 过滤关键字，工具能解决大部分日常排查。日志比如 tail -f app.log | grep -i "error\|exception"，管道一接，噪音瞬间少一大半。

但 grep 有个问题：它只给你匹配的行，丢了上下文。报错前面那几行往往才是根因。这时候得用 grep -B 5 -A 10，把前后文带出来。我自己的习惯是 -B 3 -A 15，前面看三行触发条件，后面看十五行堆栈信息，基本够用。

awk 和 sed 属于进阶操作。按时间段截取日志、统计某个接口的调用次数、提取特定字段做聚合，这些用命令行组合拳比打开 GUI 工具快得多。代价是每次都得查语法，隔几天不用就忘。

GUI 工具：适合翻旧账

命令行擅长"盯现在"，GUI 工具擅长"翻过去"。

拿 lnav 来说，它把日志文件当数据库查。自动识别时间戳格式、支持 SQL 查询、能画直方图。我第一次用它查一个 Nginx 访问日志里的慢请求分布，直接 SELECT count(*) FROM access_log GROUP BY status，比写 awk 脚本省了十几分钟。缺点是学习曲线不低，快捷键多到记不住。

GoAccess 走的是另一条路，专攻 Web 日志可视化。终端里跑起来就是一个实时仪表盘，状态码分布、访客来源、请求路径排行一目了然。排查 502 大面积爆发的时候，打开 GoAccess 比一行行翻日志直观太多。

还有一类是 ELK、Loki 这种集中式日志平台。日志量大、服务多的时候，本地工具就不够用了。但搭建和维护成本摆在那里，小团队硬上 ELK，往往是日志还没查明白，先被 Elasticsearch 的内存占用搞崩了。Loki 轻一些，配合 Grafana 用，算是个折中方案。

真正影响效率的不是工具，是日志本身

我见过最离谱的日志格式：所有信息挤在一行，没有时间戳，没有日志级别，报错和正常输出混在一起。这种日志用什么都白搭。

结构化日志（JSON 格式）配合 jq 才是舒服的组合。jq 'select(.level=="error") | .message' 一行命令精准提取。前提是写日志的人愿意多打几个字段——请求 ID、用户 ID、耗时。这些字段在排查问题时能救命。

另一个容易忽略的点：日志轮转。没配 logrotate 的服务器，迟早有一天磁盘被日志写满。到时候不是查日志的问题，是整台机器都上不去。

工具选什么，取决于你在什么场景下查日志。本地开发调试，tail 加 grep 够了。线上多服务排查，没有集中式平台会非常痛苦。但不管用什么工具，日志本身的质量决定了排查效率的上限。工具只是放大器，信号本身太弱，放大出来还是噪音。