Node.js日志中有哪些调试信息

Node.js日志中的调试信息要点

一、核心字段

• 时间戳：事件发生时间，推荐 ISO 8601 格式，便于排序与跨系统对齐。
• 日志级别：如 DEBUG/INFO/WARN/ERROR，用于过滤与告警分级。
• 进程ID（PID）：多实例/多进程时定位具体进程。
• 标签/模块/类名：标明日志来源，快速缩小范围。
• 消息体：错误描述、状态变更、业务关键点等。
• 堆栈跟踪（stack trace）：异常时输出调用栈，定位源码位置。
• 请求ID/跟踪ID：串联一次请求在多个服务/模块中的全链路日志。
• 自定义上下文：如 userId、sessionId、耗时duration、输入大小 等，用于诊断与统计。
• 主机名/服务名：在分布式/多机部署时区分来源。
  以上字段的组合能显著提升可读性与可排查性，生产环境建议使用**结构化日志（如 JSON）**承载。

二、常见调试场景与对应日志信息

• 启动与就绪：输出 端口、协议、环境、启动耗时，确认实例是否成功就绪。
• HTTP 请求/响应：记录 method、url、statusCode、响应时间、client IP、User-Agent、请求ID，必要时记录请求/响应体摘要。
• 数据库/缓存/外部依赖：记录 连接字符串/库名、目标地址与端口、超时/重试次数、错误码与堆栈，便于区分网络、鉴权、SQL 等问题。
• 异常与未捕获异常：输出 错误类型、消息、堆栈、触发路径，并附带 请求ID 与关键输入。
• 性能与慢操作：记录 关键函数/SQL 的执行时间、阈值告警，定位瓶颈。
• 配置与特性开关：打印 生效配置、特性标记、降级/熔断状态，避免“配置未生效”类问题。
• 内存与资源告警：输出 内存使用、句柄/连接数、GC 信息，辅助排查泄漏与资源枯竭。
• 定时任务/消息队列：记录 任务ID、批次、分区/队列、重试与延迟，追踪离线/异步流程。
  这些场景对应的信息点，通常可通过日志级别与上下文字段组合表达，便于检索与聚合分析。

三、日志级别与用途

• DEBUG：细粒度诊断信息，开发/排障时开启，生产默认关闭。
• INFO：关键业务事件与状态变更（如服务启动、配置加载、重要流程完成）。
• WARN：潜在问题或不影响主流程的异常（如重试、降级、可恢复错误）。
• ERROR：功能受损或需要人工介入的错误（含堆栈与必要的上下文）。
  合理设置级别并进行分级输出/过滤，能在问题发生时快速聚焦关键信息。

四、输出与运维要点

• 结构化与一致性：优先使用 JSON，统一字段命名与类型，便于检索、分析与可视化。
• 输出目标与分流：区分 控制台 与 文件，将 ERROR 单独落盘；必要时按级别分流。
• 日志轮转与保留：使用如 winston-daily-rotate-file 或系统 logrotate，控制单文件大小与保留天数，避免磁盘被占满。
• 进程管理集成：使用 PM2 时，日志默认位于 ~/.pm2/logs/，可用 pm2 logs 实时查看与追踪。
• 运行时区分输出流：区分 stdout（console.log） 与 stderr（console.error），便于重定向与告警分流。
  这些实践有助于在开发、测试、预发、生产各环境中稳定、可维护地输出与保留调试信息。

五、一条调试日志示例（JSON） { “timestamp”: “2025-12-09T10:23:45.678Z”, “level”: “debug”, “pid”: 12345, “service”: “order-service”, “requestId”: “req-abc-123”, “module”: “PaymentService”, “action”: “charge”, “userId”: “u10086”, “durationMs”: 124, “status”: “started”, “metadata”: { “orderId”: “ORD-20251209-001”, “amount”: 99.00, “currency”: “CNY” } }