小王刚接手公司一个内部管理后台，上线后总有人反馈“提交订单没反应”，但开发本地跑又没问题。他翻了下服务器上的 app.log，发现日志东一条西一条，时间格式不统一，错误堆栈被截断，还混着调试打印——查问题像在扫雷。
日志不是“有就行”，而是“得用得上”
很多新人以为只要程序能输出 log 文件，就算有了日志系统。其实不然。真正的日志系统要解决三件事：收集（把散落在各台机器、各种服务的日志聚到一起）、存储（不能今天还在，明天就清空）、检索（比如“查昨晚8点所有支付失败的请求”）。
先看自己到底要啥
别急着搜“最好用的日志系统”。打开记事本，写两行：
- 你有几台服务器？是单台 CentOS 小站，还是几十个 Docker 容器跑在 K8s 上？
- 每天大概产生多少日志？10MB？2GB？还是动不动就上百G？
如果只是个人项目或小团队内网系统，rsyslog + logrotate + grep 配合一个带搜索的 Web 界面（比如 LogViewer），完全够用。不用硬上 ELK，结果搭了三天，光调 Java 内存参数就耗掉半天。
常见组合怎么选
ELK（Elasticsearch + Logstash + Kibana）：老牌全能选手，图表丰富、搜索强大，适合中大型项目。但 Elasticsearch 吃内存，单机 4GB 内存跑起来会卡；Logstash 插件多却略重，轻量级场景可换成 Filebeat。
Loki + Promtail + Grafana：专为云原生设计，不索引日志内容，只索引标签（比如 {job="api", level="error"}），省资源、存得久。如果你已经在用 Grafana 看监控，加个 Loki 几乎零学习成本。
简单粗暴方案：Docker 用户直接用 docker logs -f --since "2h" api-service 查实时日志；Node.js 项目配个 pino + pino-pretty，本地开发时日志自动着色、折叠堆栈，眼睛轻松一大半。
一个小实验帮你判断
在服务器上执行：
find /var/log -name "*.log" -mtime -1 -size +1M | wc -l如果结果是 0 或个位数，说明日志量不大，优先考虑轻量方案；如果输出上百，就得认真规划集中式日志了。
最后提醒一句：日志格式比工具更重要。哪怕只用 echo 记录，也请统一加上时间戳和模块名，比如：
[2024-06-15 14:22:03] [user-api] login failed: invalid token格式整齐，grep 才不抓瞎，后续升级系统也少踩坑。