如何分析Node.js日志

分析Node.js日志这件事，说难不难，说简单也不简单。很多人觉得日志就是“记几行字”，真要出问题排查时，面对一堆杂乱的输出却无从下手。今天这篇，咱们就从头捋一遍，聊聊怎么把日志真正用起来。

1. 日志收集

先得确保你的Node.js应用在勤勤恳恳地写日志。基础操作是用console.log、console.error这些内置方法，但生产环境里，更推荐用winston、morgan这样的专业日志库——它们能帮你控制输出级别、格式，还能把日志写到文件里。

举个winston的例子：

const winston = require('winston');
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});
logger.info('Hello, world!');

2. 日志级别

日志级别是个基本功，但经常有人用错。常见的四个级别：

• debug——调试时用的细节信息，线上环境一般关掉。
• info——正常业务流转的记录，确认程序按预期跑。
• warn——出了点小意外，但应用还能撑住。
• error——出大事了，某个功能直接挂了。

关键点：别把所有信息都打成error，也别把严重问题随手写成info。级别设置不合理，分析时等于大海捞针。

3. 日志格式

格式上，强烈推荐用JSON。原因很简单——机器好解析，人类也能看。JSON格式的日志，扔给ELK、Graylog之类的工具，直接就能结构化分析，省去一堆正则解析的麻烦。

4. 日志轮转

日志文件越滚越大，是个常见坑。你想象一下，如果日志文件像滚雪球一样越来越大，最后会怎样？打开慢、查问题难，甚至可能把磁盘撑爆。解决方案就是日志轮转，比如logrotate，按时间或大小切分文件，自动清理旧的。

5. 日志分析工具

工具千千万，但真正好用的其实就那么几套。下面这几个是行业里用得最多的：

a. ELK Stack (Elasticsearch, Logstash, Kibana)

• Elasticsearch：负责存和搜，速度快得很。
• Logstash：负责收、处理、转发，像个管道工。
• Kibana：负责把数据可视化，画图、做仪表盘。

b. Graylog

• 集中式日志管理平台，支持各种输入和输出插件，配置相对简单。

c. Splunk

• 商用的，功能强大，但价格不便宜。大公司用得比较多。

d. Fluentd

• 开源的数据收集器，轻量级，适合做统一日志层。

e. Grafana Loki

• 轻量级的日志聚合系统，和Prometheus搭配起来效果很好，适合已经用Prometheus监控的团队。

6. 自动化分析

手动翻日志找问题，效率太低。写个脚本自动化分析，才是正经事。比如用Python读日志文件，统计某个级别的错误出现次数：

import re

def analyze_logs(log_file):
    error_count = 0
    with open(log_file, 'r') as file:
        for line in file:
            if 'ERROR' in line:
                error_count += 1
    print(f'Total errors: {error_count}')

analyze_logs('combined.log')

当然，这只是个最简单的小例子。实际生产环境，你可以把分析逻辑做得更细，比如按时间维度统计、关联多个日志源、甚至自动触发告警。

7. 监控和告警

光记录和分析还不够，得让系统在出问题时主动通知你。Prometheus + Grafana是经典组合，可以设定阈值——比如每分钟error日志超过某个数，就发告警。这样你就不用天天盯着日志看了，机器帮你盯着。

8. 定期审查

最后，定期翻翻日志，不是为了找bug，而是为了发现潜在的风险和改进点。比如某个接口频繁报warn，可能意味着设计上需要优化；某些error集中在特定时间段，可能是并发压力导致的。这种主动审查，比等着出故障再排查，要省心得多。

说到底，日志分析的精髓在于——把被动记录变成主动洞察。工具和方法都摆在这了，关键是动手实践。