Dashboard Builder

这个技能能帮你做什么

做监控不是把能采集到的指标都堆到屏幕上，而是为了解决实际问题。这个技能帮你设计真正有用的监控仪表盘——运维人员看一眼就知道系统有没有问题、问题出在哪里、该不该采取行动。

简单说，它能帮你：

• 聚焦问题 —— 围绕运维最关心的核心问题设计仪表盘（健康吗？慢了吗？资源够吗？）
• 精简面板 —— 只保留真正有用的指标，剔除"为了好看而存在"的无效面板
• 分层展示 —— 从概览到细节，一层层深入，先看整体再看局部
• 设置阈值 —— 给关键指标设置告警线，异常状态一目了然
• 支持多平台 —— Grafana、SigNoz 等主流监控平台都适用

什么时候用

搭建监控系统时 —— 要为新系统（如 Kafka、Elasticsearch、数据库等）创建监控仪表盘

优化现有监控时 —— 当前的仪表盘信息太多、找不到重点，需要重新设计

故障排查时 —— 需要快速了解系统状态，找到问题的根源

上线新服务时 —— 确保新服务有配套的监控，能及时发现异常

评估系统状况时 —— 定期查看系统健康度、性能趋势、资源使用

核心工作流

这个技能遵循四步工作流：

1. 定义运维问题 —— 先想清楚运维人员需要回答什么问题：
   • 系统健康吗？（健康/可用性）
   • 响应慢不慢？（延迟/性能）
   • 处理了多少请求？（吞吐量/容量）
   • 资源够不够？（饱和度/资源）
   • 有什么特定风险？（服务特定风险）
2. 研究平台 —— 了解目标监控平台的特性：
   • 查看现有的仪表盘是怎么组织的
   • 了解查询语言和变量设置
   • 熟悉告警阈值和颜色样式的配置方式
3. 构建最小可用仪表盘 —— 按四个层次组织：
   • 概览层 —— 一眼看出整体状态（健康、性能、资源）
   • 性能层 —— 响应时间、吞吐量、错误率
   • 资源层 —— CPU、内存、磁盘、网络的使用情况
   • 服务特定层 —— 针对具体服务的特殊指标（如 Kafka 的消费者延迟）
4. 剔除无用面板 —— 每个面板都要回答一个真实问题，否则删除

典型场景示例

Elasticsearch 集群监控

• 集群整体健康状态（红/黄/绿）
• 分片分配情况（是否有未分配的分片）
• 搜索延迟（平均/95分位/99分位）
• 索引速率（每秒写入量）
• JVM 内存和垃圾回收情况

Kafka 集群监控

• 可用 Broker 数量
• 副本不足的分区数
• 消息进出速率
• 消费者延迟（消费进度是否跟上生产速度）
• 磁盘和网络压力

API 网关/入口监控

• 请求速率（每秒请求数）
• 响应延迟（50%/95%/99%分位）
• 错误率（4xx、5xx 占比）
• 上游服务健康状态
• 活跃连接数

怎么用

从零搭建时 —— 告诉它"我要监控 Elasticsearch 集群"，它会建议你关注哪些指标、怎么组织仪表盘

优化现有仪表盘时 —— 把现有的仪表盘给它看，它会告诉你哪些面板有用、哪些可以删除

排查问题时 —— 说"系统好像有问题"，它会帮你确定需要看哪些指标来定位问题

设计告警时 —— 它会建议关键指标的告警阈值设置（如 CPU > 80% 告警）

最佳实践建议

• 先问问题，再找指标：不要先收集指标再想怎么展示
• 每个面板都要有明确的目的："这个面板回答了什么问题？"
• 颜色要有意义：绿色=健康、黄色=警告、红色=严重
• 默认时间范围要合理：通常是最近几小时到一天
• 支持变量过滤：让用户能按环境、服务名等维度筛选
• 定期回顾：业务变化后，监控也要跟着调整

质量检查清单

交付前检查：

• 仪表盘 JSON 格式正确
• 面板分组清晰，层次分明
• 每个面板都有标题和单位
• 阈值和状态颜色有意义
• 设置了常用的筛选变量（如环境、服务名）
• 默认时间范围和自动刷新间隔合理
• 没有为了好看而存在的无效面板

适用场景

• 为新系统搭建监控仪表盘
• 优化现有的监控仪表盘
• 故障排查时需要快速了解系统状态
• 评估系统的健康度和性能趋势
• 设计监控告警策略

不适用场景

• 纯数据分析（如业务报表、用户行为分析）
• 安全监控（如入侵检测、漏洞扫描，需要专门的安防工具）
• 日志分析（虽然监控和日志相关，但这个技能主要关注指标仪表盘）
• 代码级别的调试（如单步跟踪、断点调试）