Excalidraw镜像内置监控系统，保障AI服务稳定性

Excalidraw镜像内置监控系统，保障AI服务稳定性

在如今远程协作成为常态的开发环境中，可视化工具早已不再是“锦上添花”，而是团队沟通、架构设计和产品迭代的核心基础设施。Excalidraw 凭借其手绘风格的亲和力与极简交互，迅速从众多白板工具中脱颖而出。更关键的是，随着 AI 能力的集成——比如输入一句“画一个微服务注册中心架构”，就能自动生成拓扑图——它的生产力价值被大幅提升。

但问题也随之而来：AI 模型推理不稳定、响应延迟高、资源占用突增……这些问题一旦发生，用户感知极为明显。“为什么又卡住了？”“生成一张图要等十秒？”这类反馈如果频繁出现，再好的功能也会失去信任。

于是我们开始思考：如何让 AI 增强型 Excalidraw 不只是“能用”，而是真正“可靠”？答案不是等到出问题再去翻日志，而是从一开始就构建内嵌式可观测性——把监控能力直接打进容器镜像里，做到“出生即可见”。

这正是我们在实践中落地的一套方案：基于 Docker 镜像预集成 Prometheus 客户端、结构化日志输出和轻量级指标暴露机制，实现对 AI 推理服务的全链路监控。它不依赖外部复杂部署，开箱即用，特别适合私有化部署场景下的快速交付与稳定运维。

这套系统的本质，是将传统的“事后排查”模式转变为“实时洞察 + 主动预警”。我们不再被动等待用户报障，而是通过几个核心指标就能提前发现异常趋势：

• AI 图表生成耗时是否在变长？
• 内存使用是否缓慢爬升，暗示潜在泄漏？
• WebSocket 连接数是否突然激增，可能引发雪崩？

这些数据从哪儿来？就在 Excalidraw 容器内部。

具体来说，我们在 Node.js 后端服务中引入了 Prometheus 客户端库（如prom-client），并在关键路径上埋点。例如，每次调用 AI 生成接口时，都会记录请求计数和处理耗时：

const client = require('prom-client'); // 定义直方图：用于统计 AI 生成延迟分布 const aiGenerationDuration = new client.Histogram({ name: 'ai_generation_duration_seconds', help: 'Histogram of AI diagram generation duration', buckets: [0.5, 1, 2, 3, 5, 10] // 覆盖常见响应时间区间 }); // 记录请求数量 const aiRequestCounter = new client.Counter({ name: 'ai_generation_requests_total', help: 'Total number of AI generation requests' });

然后在实际处理函数中使用：

app.post('/api/generate', (req, res) => { const end = aiGenerationDuration.startTimer(); // 开始计时 aiRequestCounter.inc(); // 请求+1 try { const result = generateFromPrompt(req.body.prompt); end(); // 结束计时并记录 res.json(result); } catch (err) { end(); // 即使失败也记录耗时 log.error('AI generation failed', { prompt: req.body.prompt }); // 注意脱敏 res.status(500).json({ error: 'Generation failed' }); } });

同时，在容器启动时暴露/metrics端点：

app.get('/metrics', async (req, res) => { res.set('Content-Type', client.register.contentType); res.end(await client.register.metrics()); });

这样一来，只要 Prometheus Server 配置好抓取任务，就可以定期拉取这个端点的数据：

scrape_configs: - job_name: 'excalidraw-ai' static_configs: - targets: ['excalidraw-container:9090'] metrics_path: /metrics scrape_interval: 15s

配合 Grafana，我们就能看到清晰的仪表盘：QPS 曲线、P95 延迟趋势、错误率变化……一切尽在掌握。

当然，仅有指标还不够。日志同样重要，但我们坚持两个原则：结构化输出和敏感信息脱敏。

所有日志统一通过pino或winston输出到 stdout，并采用 JSON 格式，便于后续被 Fluentd 或 Loki 收集：

{ "level": 30, "time": 1712345678901, "msg": "AI generation completed", "durationMs": 1420, "userId": "user-123", "traceId": "trace-abc" }

注意，prompt内容不会直接打印，避免泄露用户意图或敏感架构信息。可以通过哈希或采样方式做匿名化分析。

至于资源层面的监控，则交由 cAdvisor 或 Node Exporter 来完成。它们负责采集容器级别的 CPU、内存、网络 IO 等基础指标。最终，Prometheus 把应用层指标和系统层指标关联起来，形成完整的观测视图。

比如，当发现ai_generation_duration_seconds持续上升时，我们可以同步查看container_memory_usage_bytes是否接近上限。如果是，那很可能是 GC 频繁触发导致性能下降；如果不是，也许就是模型本身负载过高，需要优化推理逻辑或增加缓存。

告警策略也因此变得更有意义。我们设置了几条关键规则：

# prometheus-rules.yml groups: - name: excalidraw.rules rules: - alert: AIGenerationTooSlow expr: histogram_quantile(0.95, rate(ai_generation_duration_seconds_bucket[5m])) > 3 for: 5m labels: severity: warning annotations: summary: "AI generation is slow (P95 > 3s)" description: "Over the last 5 minutes, P95 latency exceeded 3 seconds." - alert: ServiceDown expr: up{job="excalidraw-ai"} == 0 for: 1m labels: severity: critical annotations: summary: "Excalidraw AI service is down" description: "The target has been unreachable for more than 1 minute." - alert: HighMemoryUsage expr: container_memory_usage_bytes / container_memory_limit_bytes > 0.8 for: 10m labels: severity: warning annotations: summary: "Container memory usage high" description: "Memory usage exceeds 80% of limit for over 10 minutes."

这些规则经 Alertmanager 统一管理，支持去重、分组和静默，避免半夜被同一问题刷屏。通知渠道可根据环境配置：测试环境走钉钉群，生产环境则发邮件+企业微信+短信多重保障。

整个架构看起来并不复杂，但却解决了最现实的问题。在一个典型的 Kubernetes 部署中，它的形态如下：

graph TD A[Client Browser] -->|HTTPS/WSS| B(Excalidraw Pod) B --> C[Frontend React] B --> D[Backend Node.js] D --> E[/api/generate → AI Model] D --> F[/metrics endpoint] D --> G[stdout structured logs] F --> H[(Prometheus Server)] G --> I[(Loki/Fluentd)] H --> J[Grafana Dashboard] H --> K[Alertmanager] K --> L[Email/DingTalk/WeCom] subgraph "Cluster Level" H; I; J; K end style B fill:#e6f7ff,stroke:#1890ff style H fill:#f9f0ff,stroke:#722ed1 style K fill:#fffbe6,stroke:#faad14

可以看到，Excalidraw Pod 自身只承担“被观测”的角色，不负责存储也不渲染图表，完全符合云原生设计理念。所有的聚合、查询、告警都由集群级组件完成，职责清晰，扩展性强。

而在资源受限的小型部署中，也可以简化为单机模式：使用docker-compose启动 Excalidraw + Prometheus + Grafana 三件套，依然能获得完整的监控能力。

下面是一个推荐的docker-compose.yml片段：

version: '3.8' services: excalidraw: image: my-excalidraw-ai:latest ports: - "8080:80" expose: - "9090" environment: - ENABLE_METRICS=true logging: driver: "json-file" options: max-size: "10m" max-file: "3" resources: limits: memory: 512M cpus: "1.0" networks: - monitoring prometheus: image: prom/prometheus:latest ports: - "9091:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml networks: - monitoring grafana: image: grafana/grafana:latest ports: - "3000:3000" environment: - GF_SECURITY_ADMIN_PASSWORD=secret networks: - monitoring networks: monitoring: driver: bridge

这样的组合非常适合中小企业或内部工具团队快速上线一个“自带监控”的 AI 白板服务，无需额外搭建整套 SRE 体系也能做到基本可观测。

回过头看，这套方案之所以有效，是因为它抓住了三个关键点：

1. 轻量化集成：监控代码侵入性极低，仅增加少量依赖和几行埋点，不影响主流程。
2. 标准化输出：指标遵循 Prometheus 规范，日志采用结构化格式，天然适配主流生态。
3. 自动化响应：告警规则明确，通知链路闭环，真正实现了“故障自发现”。

更重要的是，这种“镜像级监控”的思路，其实可以推广到任何类似的 Web 应用增强场景。无论是集成大模型、OCR、语音识别还是图像处理，只要涉及后台异步计算，都可以沿用这套模式：在服务内部暴露指标，在容器外集中观测。

未来我们还计划进一步深化这套体系。比如：

• 引入 OpenTelemetry 实现分布式追踪，跟踪一次生成请求从前端到 AI 模型的完整链路；
• 基于历史指标训练简单预测模型，提前预判资源瓶颈；
• 将用户行为（如常用命令、高频操作）匿名化后用于优化提示词工程。

但归根结底，所有智能化演进的前提，都是系统足够稳定、足够透明。而内置监控，正是通往这一目标的第一步。

今天，我们不再满足于“做出一个能跑的功能”，而是追求“做出一个让人放心使用的系统”。Excalidraw 镜像中的那一行/metrics端点，不只是技术细节，更是一种态度：真正的可靠性，是从第一天就开始设计的。