日志分析基础：日志级别、常用日志工具（ELK、grep）
日志分析，说白了就是故障排查的第一道防线。我接手过的故障里，有六七成都是靠日志定位的。很多人跟我说「日志太多，根本看不过来」，其实不是日志多，是你没学会怎么看。
这一节，咱们就把日志级别、grep 和 ELK 这三个核心东西捋清楚。都是实操里天天用的。
1. 日志级别 —— 故障的「红绿灯」
日志级别就是给你的日志标个严重程度。从散漫到致命，分这么几档：
| 级别 | 含义 | 生产环境建议 |
|---|---|---|
| DEBUG | 开发调试信息，极其详细 | 关掉，不然磁盘会炸 |
| INFO | 正常业务流程记录 | 保留，用来追踪链路 |
| WARN | 可能有问题但还没挂 | 必须关注，很多故障前兆 |
| ERROR | 功能异常，但进程还能跑 | 需要立刻看，但不一定致命 |
| FATAL | 系统活不下去了 | 直接报警，立刻重启 |
我习惯在项目初期就把日志模板定好。曾经有个线上事故，因为团队把大量 DEBUG 日志打到生产环境，导致磁盘在凌晨三点写满……从那之后，我就强制所有服务必须配 `LOG_LEVEL=INFO` 才允许上线。
2. grep —— 最快的手动武器
你说日志文件可能几 GB，怎么查？grep。它快、简单、不需要搭建环境。
我常用的几个 grep 组合拳：
# 基本搜索
grep "OutOfMemoryError" /app/logs/error.log
# 前后看 5 行上下文（最常用的）
grep -C 5 "Connection refused" /app/logs/service.log
# 递归目录找所有日志里的关键词
grep -r "500" /app/logs/
# 统计某个错误出现的次数
grep -c "ORA-12519" /app/logs/*.log为什么我会强调 -C 参数？因为单看一行根本不知道上下文。我曾经排查过一起诡异的 NPE，grep "NullPointerException" 命中 300 行，全是同一行代码。后来加上 -C 10 才发现，调用方传了个 null 进来，而日志只打了异常堆栈，没记入参。这教训让我现在写日志时，必须把关键参数也打出来。
grep -v 可以排除干扰。比如你在查超时，但接口返回里包含了大量正常心跳的日志，可以 grep -v "heartbeat" 把噪音过滤掉。
3. ELK 全家桶 —— 企业级日志分析
grep 适合单机、小场景。但如果你要跨几十台机器，跨小时段，跨应用去追踪一次用户请求，grep 就力不从心了。这时候我首选 ELK。
ELK 三件套各司其职：
| 组件 | 角色 | 我关注的参数 |
|---|---|---|
| Elasticsearch | 存储 + 搜索引擎 | 索引分片数、副本数、refresh_interval |
| Logstash | 采集、解析、转化 | grok 正则、filter 配置、input 插件 |
| Kibana | 可视化面板 | Discover 查询、Dashboard 看板、KQL 语法 |
很多新手把 ELK 搭起来就用了，结果数据一多 Elasticsearch 就 OOM。我踩过这个坑——当时没有给 Logstash 做限流，日志生产速度 100MB/s，Logstash 扛不住直接丢事件，ES 那边看到的日志是残缺的。
正确的姿势是什么？从后往前调：先确定 ES 能承受多少写入，再让 Logstash 限流，必要时用 Redis 或 Kafka 做削峰填谷。
Kibana 的 KQL 语法我也得提一嘴，很多人还以为只能用 Lucene 语法。KQL 更人性化：
# KQL 示例（在 Kibana Discover 里用）
response:500
# 表示查找 response 字段值为 500 的文档
method:POST AND status:200
# 表示 POST 请求且状态码为 200
@timestamp >= "2025-01-01" and @timestamp <= "2025-01-02"
# 范围查询，故障回滚时经常用我曾用 ELK 帮业务定位过「订单重复支付」的故障。几台应用服务器各自打不同的 traceId，以前 grep 得一台一台查，再拼起来。ELK 里直接用 traceId 搜索，一分钟内看到了完整的调用链路——数据库连接池耗尽的真相一目了然。
4. 日志分析整体框架
把上面这些串起来，日志分析其实就三个动作：产生 → 收集 → 分析。下面这张图帮你理清脉络：
小结
日志分析这件事，没有什么花哨的捷径。我的经验就三条：
- 级别要对——生产只打 INFO 及以上，WARN 和 ERROR 必须盯住；
- grep 要熟——三五秒钟内能写出正确的查找命令，排查速度翻倍；
- ELK 要稳——从写日志开始就设计好字段，搭平台时先压测 ES 写入能力。
我见过太多人「上了 ELK 就不管了」，结果出故障时发现日志没采集到、索引坏了、或者 ES 打满了。所以说到底，工具只是手段，你对日志的理解和重视，才是排查效率的真正来源。