Excalidraw呈现监控拓扑：故障定位更迅速
在一次深夜的线上告警中，某电商系统的支付服务突然出现大面积超时。运维团队迅速集结，但问题迟迟未能定位——有人盯着Grafana面板，有人翻查日志，还有人在飞书文档里手绘调用链路图。直到一位工程师把几张零散图表拼在一起，才终于发现是某个被忽略的缓存依赖节点出现了雪崩。这样的场景，在现代分布式系统中并不少见。
当微服务数量从几十增长到上百，服务间的调用关系变得错综复杂，传统的监控工具虽然能提供丰富的指标数据，却难以构建直观的“全局视图”。而一张清晰的监控拓扑图，往往能在关键时刻成为破局的关键。
正是在这种背景下，Excalidraw逐渐走入技术团队的视野。它不是什么重型架构设计平台，也不是专业的可视化分析引擎，而是一个轻量、开放、支持实时协作的虚拟白板工具。但它恰恰以极简的设计哲学，解决了故障排查中最棘手的问题：如何在最短时间内，让所有人对系统状态达成共识。
Excalidraw 的核心魅力在于它的“低门槛高表达力”。你不需要是设计师，也不必精通绘图软件，只需打开页面，拖几个方框，画几条线，就能快速勾勒出当前系统的调用结构。更重要的是，这种表达是动态的、可协作的、可追溯的。
想象这样一个场景：告警触发后，值班工程师一键生成基础拓扑图，系统自动从Consul拉取服务依赖，并通过AI插件将“用户中心 → 订单服务 → 支付网关”的调用链可视化。紧接着，多位同事同时进入同一个画布，一人标注数据库延迟异常，另一人圈出消息队列积压区域，第三位则直接在节点旁添加注释：“昨天上线了新版本，怀疑有连接泄漏。” 所有操作实时同步，光标位置清晰可见，讨论不再依赖文字转述，而是围绕同一张图展开。
这背后的技术实现并不简单。Excalidraw 基于 TypeScript + React 构建前端界面，使用 Canvas API 进行图形渲染，所有元素（矩形、箭头、文本）都以 JSON 格式存储，包含坐标、样式、绑定关系等元数据。当你移动一个服务节点时，与其相连的箭头会自动跟随调整——这得益于startBinding和endBinding字段的支持，它们记录了连线与图形之间的逻辑关联，而非固定坐标。
更进一步，Excalidraw 支持 Operational Transformation（OT）或 CRDT 机制处理多用户并发编辑冲突，确保多人协作时不产生数据不一致。其“本地优先”（local-first）设计理念允许用户离线操作，变更在网络恢复后自动同步，非常适合网络环境不稳定或对隐私要求高的场景。
而对于希望提升建模效率的团队，Excalidraw 还可通过集成 OpenAI 等外部 AI 服务，实现自然语言驱动绘图。例如输入“画一个包含 Nginx、Node.js 和 MySQL 的三层架构”，AI 模块会解析语义，识别出三个节点及其层级关系，并调用绘图引擎完成初步布局。这种方式尤其适用于突发事件中的快速建模，几分钟内即可完成原本需要半小时的手动绘制。
下面是一段典型的程序化创建拓扑图的代码示例：
// 使用Excalidraw的programmatic API创建一个简单的服务拓扑 import { ExcalidrawElement } from "@excalidraw/excalidraw/types/element/types"; const commonProps = { type: "rectangle", version: 1, versionNonce: 0, isDeleted: false, fillStyle: "hachure", strokeWidth: 2, strokeStyle: "solid", roughness: 2, opacity: 100, angle: 0, width: 120, height: 60, seed: 123456, groupIds: [], shape: null, boundElements: [], }; const lineCommonProps = { type: "arrow", strokeColor: "#000", strokeWidth: 2, endArrowhead: "arrow", startArrowhead: null, }; const elements: ExcalidrawElement[] = [ { ...commonProps, id: "nginx-server", x: 100, y: 100, strokeColor: "#c92a2a", backgroundColor: "#fff", }, { ...commonProps, id: "nodejs-app", x: 300, y: 100, strokeColor: "#1971c2", }, { ...commonProps, id: "mysql-db", x: 500, y: 100, strokeColor: "#2b8a3e", }, // 添加连接线：Nginx -> Node.js { type: "arrow", points: [ [0, 0], [80, 0], [80, 40], [180, 40], ], startBinding: { elementId: "nginx-server", focus: 0.5, gap: 10, fixedPoint: null, }, endBinding: { elementId: "nodejs-app", focus: 0.5, gap: 10, }, ...lineCommonProps, }, // Node.js -> MySQL { type: "arrow", points: [[0, 0], [100, 0]], startBinding: { elementId: "nodejs-app", focus: 0.5, gap: 10, }, endBinding: { elementId: "mysql-db", focus: 0.5, gap: 10, }, ...lineCommonProps, } ];这段代码展示了如何通过 Excalidraw 的底层数据模型，手动构造一个三层服务架构图。每个rectangle表示一个服务节点，arrow表示调用关系。关键在于startBinding和endBinding的设置，它们实现了箭头与矩形的智能绑定——即使后续移动节点，连线也会自动重绘并保持连接，极大提升了拓扑图的可维护性。
这一能力可以被封装成自动化脚本。比如，从 CMDB 或 Kubernetes Service 中读取服务依赖关系，自动生成对应的 JSON 结构并导入 Excalidraw，作为故障排查的初始画布。结合 Prometheus 的指标查询接口，甚至可以在节点上叠加显示 P99 延迟、错误率等 KPI，形成“活”的监控拓扑。
在实际部署中，Excalidraw 通常作为前端可视化层嵌入到内部运维平台中。典型架构如下：
[服务发现系统] → [拓扑生成服务] → [Excalidraw Editor] ↓ ↑ [Prometheus/Grafana] [AI 插件] ↓ ↓ [告警触发] ← [用户交互画布]- 服务发现系统（如 Consul、K8s Service）提供运行时的服务实例和依赖；
- 拓扑生成服务负责将这些信息转换为 Excalidraw 兼容的 JSON；
- Excalidraw Editor作为核心交互组件，嵌入至企业门户；
- AI 插件监听用户输入，支持自然语言快速修改拓扑；
- Grafana/Prometheus提供实时指标，可在点击节点时联动展示。
整个工作流程也变得高度协同：
- 监控系统检测到某服务延迟突增，触发告警；
- 工程师进入运维平台，点击“启动拓扑诊断”；
- 系统自动加载受影响服务的基础拓扑；
- 输入“标记最近5分钟错误率>5%的服务”，AI 高亮可疑节点；
- 多人同时编辑画布，使用颜色、标签、批注标注推理路径；
- 点击异常节点，右侧弹出该服务在 Grafana 中的监控面板；
- 定位根因后，保存画布截图并归档至事故报告系统。
这个过程不仅加快了响应速度，更重要的是形成了可追溯的知识资产。以往的故障复盘往往依赖事后整理的文字描述，容易遗漏细节。而现在，整张带批注的拓扑图本身就是一份完整的上下文记录，未来回顾时仍能还原当时的判断逻辑。
当然，在落地过程中也有一些值得考虑的设计要点：
- 安全性：默认情况下 Excalidraw 内容保存在浏览器本地，适合临时协作。但在生产环境中，应启用访问控制，限制敏感架构图的分享与下载权限，防止截屏泄露。
- 性能优化：当画布元素超过500个时，Canvas 渲染可能出现卡顿。建议采用分层渲染策略，或按区域懒加载，避免一次性渲染全图。
- 标准化模板：为提升一致性，可预设常用组件库（如“数据库”、“消息队列”、“API网关”），并通过 Library 功能共享给团队成员，减少重复劳动。
- 系统集成：推荐通过 iframe 嵌入方式将 Excalidraw 集成进现有平台，并利用其事件 API 监听用户操作，实现行为审计与操作追踪。
- 移动端适配：目前触控体验尚不完善，建议关键操作仅在桌面端执行，移动端主要用于查看。
值得一提的是，Excalidraw 的手绘风格并非为了“好看”，而是一种深思熟虑的认知设计。轻微抖动的线条模拟人类手写效果，降低了正式图表带来的压迫感，反而更容易激发自由讨论。相比规整冷峻的矢量图，这种“不完美”的视觉风格更贴近真实会议中的白板草图，有助于打破沟通壁垒，尤其是在跨职能团队协作时表现尤为突出。
展望未来，随着 AIGC 技术的发展，Excalidraw 的潜力将进一步释放。我们可以设想一种闭环场景：系统从日志中检测到异常模式，LLM 自动推测可能的传播路径，并在 Excalidraw 画布上动态修正拓扑结构，提示“此处可能存在未注册的依赖”。此时，它已不再只是一个绘图工具，而是一个具备推理能力的“智能运维画布”。
对于 SRE 团队而言，真正的稳定性建设不仅是修复故障，更是构建快速响应的能力体系。而 Excalidraw 正是以其轻盈之姿，撬动了传统监控生态中长期存在的“可视化断层”。它提醒我们：有时候，解决问题的关键不在于采集更多数据，而在于如何让更多人更快地理解这些数据。
这种高度集成的设计思路，正引领着智能运维向更可靠、更高效的方向演进。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
