Debian JS日志如何监控

Debian 上监控 Ja vaScript 日志的实用方案

一 场景与总体架构

聊到Ja vaScript日志监控，首先得把场景分清楚。前端和后端，完全是两码事。

前端 JS（浏览器）这块，核心是捕捉运行时的错误和用户行为。通常的做法是接入像 Sentry 这类专业的前端异常监控服务。当然，开发阶段也离不开浏览器控制台和开发者工具，用来实时观察错误堆栈和网络请求的动向。

后端 Node.js（服务端）则是另一套逻辑，重点在于日志的采集、检索和后续的告警。这里建议采用 Winston、Bunyan 或 Morgan 这类库来输出结构化的日志。日志的去向，要么交给 systemd/journalctl 管理，要么直接写入文件。之后，再通过 ELK（Elasticsearch, Logstash, Kibana）或 Graylog 这样的集中式平台进行统一的分析和可视化，这才是完整的闭环。

二 快速上手 本地与实时查看

在深入搭建复杂系统之前，掌握一些本地快速查看日志的方法非常有用。

系统与服务日志

• 想实时盯着系统日志？一条命令搞定：journalctl -f。
• 只看某个特定服务的日志？试试 journalctl -u your-js-app -f。
• 需要回溯最近一段时间？journalctl --since “1 hour ago” 就能帮你定位。

应用日志文件

• 如果日志是直接写到文件的，用 tail -f /var/log/your-app/*.log 可以实时跟踪。
• 想快速过滤错误信息？结合 grep 就行：tail -f app.log | grep “error”。

前端实时调试

• 前端就更简单了，在浏览器里按 F12 打开开发者工具，所有错误和日志信息都在 Console 面板里一目了然。

三 Node.js 服务端监控落地

要让服务端的日志真正可管理、可运维，需要一些系统性的工作。

结构化日志输出

• 第一步是规范输出。使用 Winston、Bunyan 或 Morgan 等库，将日志按级别（如 info、warn、error）进行结构化输出，并同时写入控制台和文件。这为后续的检索和设置告警规则打下了基础。

systemd 托管与集中

• 将 Node.js 应用交给 systemd 托管是个好习惯。下面是一个服务单元文件的示例：

[Unit]
Description=My Node.js App
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/myapp/app.js
Restart=always
User=www-data
Environment=NODE_ENV=production
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=my-js-app

[Install]
WantedBy=multi-user.target

• 配置好后，执行以下命令启用并查看日志：

sudo systemctl daemon-reload
sudo systemctl enable --now my-js-app
sudo journalctl -u my-js-app -f

集中式日志平台

• 当服务多了以后，集中管理是必然选择。ELK 栈是经典方案：用 Filebeat 或 Logstash 采集日志到 Elasticsearch，然后在 Kibana 中建立索引模式（例如 nodejs-logs-*）和可视化看板。
• 另一个优秀的选择是 Graylog，它同样提供了强大的日志聚合、检索和告警功能，特别适合对多个服务的日志进行统一治理。

四 前端 JS 异常监控

前端的错误往往稍纵即逝，因此需要主动捕获和上报。

代码埋点与错误捕获

• 全局异常：通过 window.onerror 和 unhandledrejection 事件来捕获未处理的同步和异步错误。
• 资源加载错误：监听 error 事件，可以捕捉到图片、脚本等资源加载失败的情况。
• 网络请求异常：对 fetch 或 axios 等网络请求库进行统一拦截，记录下状态码、请求耗时和异常响应。

接入 Sentry（示例）

• 以业界流行的 Sentry 为例，首先安装 SDK：npm install @sentry/browser
• 然后在应用入口进行初始化：

import * as Sentry from “@sentry/browser”;

Sentry.init({
  dsn: “YOUR_DSN”,
  environment: “production”,
  release: “1.0.0”,
  tracesSampleRate: 1.0, // 性能追踪采样率
});

• 关键一步：结合 source map 文件的上传，Sentry 就能在后台还原经过压缩混淆后的错误堆栈，让你在复杂的生产环境中也能准确定位到源码级别的错误位置。

五 告警与最佳实践

日志收集起来不是目的，产生 actionable 的洞察才是。

告警策略

• 错误率阈值：例如，当 HTTP 5xx 或 4xx 状态码的比例超过设定值，或者单位时间内 ERROR 级别的日志数量激增时，立即触发告警。
• 关键字告警：在日志流中设置关键词监控，一旦出现 “OutOfMemory”、“EADDRINUSE”、“timeout” 等致命错误关键字，马上通知相关人员。
• 指标联动：将日志监控与 Prometheus + Grafana 构建的指标监控体系联动。对进程存活状态、接口响应时延、内存占用等设置阈值告警，一旦触发，再结合当时的日志进行根因定位，效率倍增。

日志规范与治理

• 统一字段：制定并遵守日志字段规范，通常应包含 timestamp、level、service、env、trace_id、msg、err.stack 等核心字段，便于后续的解析和关联分析。
• 采样与脱敏：在生产环境中，对 DEBUG 或 TRACE 这类低级别日志进行采样输出，避免数据量过大。同时，务必对日志中的敏感信息（如密钥、个人信息）进行脱敏处理，防止泄露。
• 保留与归档：制定合理的日志保留策略，按日或周进行日志文件滚动。对于不常访问的冷数据，可以归档到对象存储中，以有效控制存储成本。

安全与合规

• 最后但同样重要的一点是安全。必须严格限制对原始日志文件的访问权限，防止敏感数据泄露。对外只提供必要的、经过鉴权的查询和可视化接口，确保整个日志系统的操作符合安全与合规要求。