Linux Node.js日志级别如何设置更合理

在Linux环境下折腾Node.js应用，日志级别这玩意儿看着简单，但设置不合理，要么调试时抓瞎，要么被日志刷爆磁盘。今天就来聊聊，怎么根据实际场景把日志级别调得更顺手。

先搞清楚日志级别有哪些

Node.js生态里常见的日志级别，从低到高大致分为四档：debug、info、warn、error。debug最啰嗦，什么细节都往外吐；info记录常规运行状态；warn提示你注意但不致命的问题；error自然就是出错时用的。记住了这四档，后面就好办了。

环境不同，级别不同

最朴素的道理：开发环境恨不得把每条变量变化都打出来，生产环境呢？只关心警告和错误就够了。一个非常实用的做法是用环境变量来控制级别，比如这样：

const logLevel = process.env.LOG_LEVEL || 'info';

这样在开发机上设成debug，生产机上不设或者设成warn，一套代码就搞定了。

第三方日志库能省不少事

如果只用console.log，后面处理起来会相当痛苦。行业里常用的winston、bunyan这些库，天然支持日志级别控制、日志轮转、格式化输出，甚至还能对接外部日志系统。值得花时间选一个用起来顺手的。

代码里怎么分级

写日志不是简单粗暴地全用console.log。比如一个请求超时但还能重试，可以打warn；如果数据库连不上了，那就必须error。关键是要遵循一个原则：越低级别的日志，越应该只在排查问题时才有用。别把业务逻辑里的常规提示也写成error，那样会污染告警通道。

小心日志“爆炸”

线上环境如果开了debug级别，用不了多久磁盘就会报警。除了设置合理级别，还得配合日志轮转策略——比如按天、按大小切分，保留最近N天的文件。这样既不会丢关键信息，也不会让磁盘被撑爆。

日志不只是存着，要会用

日志写出来不是用来落灰的。定期翻看、分析异常模式，才能提前发现问题。像ELK（Elasticsearch、Logstash、Kibana）或Graylog这类工具，能把分散的日志集中起来，做可视化搜索和告警。对生产环境来说，这是标配。

说到底，日志级别没有放之四海皆准的黄金配置。每个应用对信息的需求不一样，得在实际运行中反复调优。核心思路就一句话：保证你能看到需要的信息，又不会让冗余日志反噬性能。多试几次，自然就找到平衡点了。