Excalidraw报警阈值设定：CPU/内存/延迟

Excalidraw报警阈值设定：CPU/内存/延迟

在现代技术团队的日常协作中，可视化工具早已不再是“锦上添花”，而是不可或缺的生产力引擎。Excalidraw 以其极简的手绘风格和强大的实时协同能力，迅速成为架构设计、产品脑暴和系统建模中的首选白板工具。更进一步，随着 AI 功能的集成——比如通过自然语言自动生成流程图——它的使用密度和计算负载也在悄然攀升。

尤其是在自托管部署场景下，当多个团队并行使用、频繁调用 AI 图表生成时，服务稳定性面临真实压力。你有没有遇到过这样的情况：某天突然多人反馈“画不动了”、“光标不同步”，登录服务器一看，CPU 直冲100%，内存被吃干抹净？问题往往不是突发崩溃，而是资源缓慢爬升后失守防线。

根本原因在于：监控做了，但阈值设得不够聪明。很多运维配置只套用了通用模板，比如“CPU超80%告警”，却忽略了 Excalidraw 的实际行为模式——它轻量但敏感，低并发时安静如鸡，高互动时瞬间爆发。真正的挑战，是如何为这种“动静结合”的应用设定既不过敏也不迟钝的报警边界。

我们不妨从三个最关键的性能维度切入：CPU 使用率、内存占用、网络延迟。它们不是孤立指标，而是共同构成用户体验的“铁三角”。任何一个失守，都会让“流畅协作”变成“卡顿等待”。

先说CPU 使用率。很多人以为 Excalidraw 是前端主导的应用，后端几乎不耗资源。这在过去是对的，但现在如果你开启了 AI 生成功能，情况就完全不同了。一次text-to-diagram请求背后，可能是 NLP 模型解析 + 图结构生成 + SVG 渲染链路的全栈计算，尤其在没有 GPU 加速的情况下，全部压在 CPU 上。Node.js 主进程一旦被阻塞，WebSocket 心跳都可能延迟，进而影响所有协作者。

所以，监控不能只看平均值。瞬时峰值可以容忍，但持续超过某个水位就必须干预。我们通常建议：

• 一般负载场景：设置>80% 持续5分钟触发 warning；
• 启用 AI 功能时：降为>70%，并配合自动扩缩容（如 Kubernetes HPA）提前分流请求。

下面是 Prometheus 中常用的表达式：

- alert: HighCpuUsage expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "High CPU usage on instance {{ $labels.instance }}" description: "CPU usage is above 80% for more than 5 minutes. Current value: {{ $value }}%"

这里的关键是irate([5m])——它只取最近两次采样点来估算增长速率，对突发负载非常敏感。相比rate()更适合捕捉短期飙升。但也要注意，太敏感容易误报，因此加上for: 5m才能过滤毛刺。

再来看内存占用。这是最容易被忽视的风险点。Excalidraw 基于 Node.js 构建，而 V8 引擎的内存管理虽然高效，但也意味着一旦出现闭包引用未释放、事件监听器堆积等问题，内存会缓慢上涨，直到某一刻触发 OOM Killer，整个服务直接退出。

更麻烦的是，这类泄漏往往是渐进式的。白天用得好好的，晚上用户量下降后本该释放内存，结果发现 RSS 依然居高不下。等到第二天早高峰来临，新连接一涌入，雪崩发生。

我们的经验是：不要等出事才查。应该从部署第一天就开始观察内存趋势，并设定两个层级的预警：

• Warning 级别：使用量达到容器限制的 80%
• Critical 级别：接近 95%，立即触发扩容或重启策略

例如，在docker-compose.yml中明确限制资源：

services: excalidraw: image: excalidraw/excalidraw:latest container_name: excalidraw mem_limit: 1g restart: unless-stopped ports: - "5000:5000"

然后通过 cAdvisor 或 Node Exporter 抓取实际使用量。Prometheus 报警规则如下：

- alert: HighMemoryUsage expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 80 for: 10m labels: severity: warning annotations: summary: "High memory usage on {{ $labels.instance }}" description: "Memory usage has exceeded 80% for over 10 minutes. Current: {{ $value }}%"

值得一提的是，Node.js 默认有 1.4GB 左右的堆内存上限（32位系统更低）。即使宿主机还有空闲内存，V8 也无法使用。因此，除了系统级监控，也建议开启--max-old-space-size参数进行容器内控制，比如：

node --max-old-space-size=8192 server.js

将最大堆设为 8GB，避免因默认限制导致“明明有内存却用不了”的尴尬。

第三个维度，也是最贴近用户体验的——网络延迟。你可以接受偶尔重算一下图形，但无法忍受“我画一笔，对方三秒后才看到”。Excalidraw 依赖 WebSocket 实现毫秒级同步，任何环节的延迟都会破坏协作节奏。

延迟来源多样：可能是客户端到服务器的地理距离太远，也可能是中间 CDN 节点拥塞，或者是服务端处理不过来，积压了消息队列。传统的 ICMP Ping 只能测通路延迟，无法反映真实应用层表现。我们需要的是端到端的应用层 RTT 测量。

一个有效的做法是在前端注入心跳机制：

const ws = new WebSocket('wss://your-excalidraw-server/ws'); let heartbeatInterval; let lastPing = null; ws.onopen = () => { heartbeatInterval = setInterval(() => { lastPing = Date.now(); ws.send(JSON.stringify({ type: 'ping' })); }, 10000); // 每10秒一次 }; ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'pong') { const latency = Date.now() - lastPing; console.log(`Latency: ${latency}ms`); reportLatencyMetric(latency); // 上报至 Pushgateway 或埋点服务 if (latency > 300) { showNotification("网络延迟较高，协作可能受影响"); } } };

这个简单的ping/pong协议能真实还原用户视角的响应时间。我们将采集到的数据推送到 Prometheus Pushgateway，再由 Prometheus 统一拉取分析：

- alert: HighClientLatency expr: avg by(job) (client_latency_ms) > 300 for: 5m labels: severity: warning annotations: summary: "High average client latency for {{ $labels.job }}" description: "Average client round-trip latency exceeds 300ms. Current: {{ $value }}ms"

一旦均值持续超过 300ms，说明网络路径或服务处理已进入亚健康状态。这时候哪怕 CPU 和内存正常，也应该介入排查——也许是某个区域的用户集中接入导致局部拥塞，需要考虑部署边缘节点或引入就近接入策略。

整个监控体系的架构其实并不复杂：

[客户端浏览器] ↓ (HTTPS + WSS) [Nginx 反向代理] ←→ [Blackbox Exporter（主动探测）] ↓ [Excalidraw 容器] ←→ [cAdvisor → Prometheus] ↓ [Redis（可选，用于共享状态）] ↓ [Node Exporter → Prometheus] ↓ [Alertmanager → 邮件/钉钉/企业微信]

其中：
-cAdvisor + Node Exporter负责容器与主机层面的资源采集；
-Blackbox Exporter定期对服务入口发起探测，验证连通性与响应时间；
-前端上报机制补充最后一公里的真实体验数据；
- 所有指标汇总至 Prometheus，由 Alertmanager 统一调度通知。

实践中我们总结了几条关键原则：

1. 阈值要有弹性：不要死守“80%”这类数字。应结合历史基线动态调整。例如周末负载低，可适当降低阈值以提高灵敏度；工作日高峰期则放宽一点，避免噪音。
2. 分级告警必须清晰：
   - Warning：提示关注，可用于自动记录日志或发送低优先级通知；
   - Critical：需人工介入，触发电话呼叫或强提醒。
3. 报警要能驱动动作：与其让人半夜起来重启服务，不如直接对接自动化恢复流程。比如内存长期高位运行后，自动滚动更新实例；或者 AI 请求过多时，临时切换至降级模式（禁用高级生成功能）。
4. AI 模块建议独立部署：把 AI 推理拆成单独微服务，用专用资源配置和独立监控策略。这样即使 AI 队列拥堵，也不会拖垮主协作通道。

最后想强调一点：最好的报警，是你从未收到的那一次。真正成熟的监控体系，不是等到问题爆发才通知你，而是在风险积累初期就给出信号，让你有机会在用户感知之前完成修复。

Excalidraw 看似只是一个“画画工具”，但它背后的协作逻辑、状态同步机制和日益增长的智能负载，已经具备典型现代 Web 应用的所有特征。为它设定合理的报警阈值，本质上是在构建一种“预防性运维”文化——用数据代替猜测，用自动化替代救火。

当你下次打开 Excalidraw，发现无论多少人同时编辑，线条依旧流畅、操作即时同步时，请记得，那不仅是代码的胜利，更是监控与工程判断的无声守护。