很多 JavaScript 应用上线后，真正棘手的往往不是功能没写完，而是出问题时根本不知道该从哪里查。要在 Ubuntu 上把稳定性做起来，日志不能只停留在 console.log 这一层，还得把级别控制、轮转留存、集中分析和异常监控一起补齐。这样做的价值，不只是出了故障能回溯原因，更重要的是能根据日志提前发现风险，判断当前配置和代码是否已经接近稳定运行的要求。
先把日志记录做扎实
想让日志真正服务于稳定性，第一步是把记录方式标准化。开发阶段直接使用 console.log、console.error、console.warn 没问题，但到了生产环境，这种做法通常不够用。
更稳妥的选择是使用专业日志库，比如 winston 或 pino。这类工具的优势不只是“能打印日志”，而是可以进一步控制输出格式、写入文件、按条件过滤不同级别的信息，而且性能表现通常比随手拼接输出更可靠。对于需要长期维护的服务，这种规范化记录方式比零散输出更容易排查问题。
日志级别也要尽早划清边界。常见的 error、warn、info、debug 并不是越多越好，而是要明确场景：
error：用于明确失败、异常中断、关键操作不可用等问题。warn：用于未必立刻报错，但已经出现风险信号的情况。info：用于记录关键流程和运行状态。debug：用于开发或排查时观察细节。
在生产环境里，通常应以 error 和 warn 为主，避免让 debug 长期开启。否则日志量会快速膨胀，真正有价值的信息反而会被淹没，后续检索和存储成本也会一起上升。
除了记录内容本身，日志文件怎么保留同样重要。在 Ubuntu 上，logrotate 是最常见、也最实用的轮转工具。把轮转规则配置好之后，日志不会无限增大，磁盘空间也更可控；同时还能保留一定周期的历史文件，方便在故障发生后回溯前因后果。对于线上服务来说，这一步往往比“多打一条日志”更直接影响稳定运行。
业务变复杂后，日志要集中管理
当应用规模扩大，或者同一团队需要维护多台 Ubuntu 服务器、多套 JavaScript 服务时，单纯登录机器翻日志文件就会变得低效。这个阶段，集中式日志管理基本就是必需项了。
ELK Stack（Elasticsearch、Logstash、Kibana）和 Graylog 都是常见方案。它们的核心价值在于把分散的日志统一汇聚起来，再提供检索、分析和可视化能力。这样一来，排查问题时不必反复 SSH 到不同服务器上找文件，而是可以直接从统一界面查看全局日志流，效率会明显高很多。
集中管理真正带来的变化，不只是“看起来更整齐”，而是能让日志从事后排障工具，升级为日常运维分析的一部分。比如：
- 同类错误可以被快速聚合，便于识别是否为系统性问题。
- 跨服务调用链上的异常更容易串联起来看。
- 不同时间段的错误峰值可以直接对比，帮助判断是否与发布、流量或配置变更有关。
在此基础上，再进一步做监控和告警，日志的价值才算真正释放出来。定期人工检查日志当然有必要，但更有效的方式，是提前设置规则，让系统自动发现异常模式。比如出现特定错误关键字、异常数量突然增加，或者某类性能问题反复出现时，平台可以直接发出通知。这样处理问题的节奏就从“故障发生后再找原因”，变成“出现苗头时就开始干预”。
光有日志不够，代码层面的防御也要到位
日志体系再完整，也不能替代代码本身的健壮性。很多稳定性问题并不是“没记录下来”，而是异常没有被正确处理，导致程序直接带着模糊状态继续运行，最后把问题放大。
因此，所有可能抛出错误的关键操作，都应该有明确的异常处理逻辑。最基础的做法就是使用 try-catch，并把异常信息记录到日志中。这里尤其要保留堆栈跟踪，因为它能直接告诉你错误是从哪一段调用链冒出来的，帮助快速定位到具体代码位置，而不是只留下一个笼统的失败提示。
对 JavaScript 服务来说，这一点非常关键。因为很多线上问题表面上看是“接口返回异常”或“任务执行失败”，但真正能决定排障速度的，往往就是日志里有没有把异常上下文和堆栈完整保留下来。
除了异常处理，性能监控也应纳入稳定性体系。响应时间、内存使用、CPU 负载，这些指标都直接反映应用是否处在健康状态。如果把这些信息写入日志，或者接入 New Relic、Datadog 之类的工具持续观察，很多故障其实能在崩溃前就暴露趋势。
例如，内存泄漏往往不是突然出现的，而是表现为内存占用持续上升；响应时间恶化也常常早于用户明显感知到故障。如果这些迹象被及时记录和分析，就能在服务完全失稳之前介入，而不是等到进程崩溃后再被动收拾残局。
日志策略也需要持续复查
最后一个容易被忽略的问题是：日志策略本身并不是“一次配置、长期不动”。业务规模、访问模式、部署方式和团队协作方式都在变化，早期看起来合适的日志级别、轮转周期或集中管理规则，过一段时间可能就不再匹配现状。
更实际的做法是定期回看日志分析结果，再反过来调整系统：
- 根据高频错误优化代码实现，减少重复故障。
- 根据日志量调整日志级别，避免记录过多无效信息。
- 根据磁盘与保留需求修正
logrotate规则。 - 根据监控结果补充告警条件，缩短问题发现时间。
说到底，日志不是摆设，也不是上线后才想起来补的辅助材料。它本质上是一套诊断机制：一方面在故障发生时告诉你哪里出错了，另一方面也能在问题真正爆发前暴露隐患。对 Ubuntu 上运行的 JavaScript 应用来说，只有把记录、管理、监控和代码处理结合起来，日志才能真正转化为稳定性提升手段。
