4、可视化与监控大屏：Grafana仪表盘设计、实时数据流展示、告警规则配置
说到绿色能源系统的数字化管理，我个人觉得最直观、最有成就感的环节，就是搭一个漂亮的监控大屏。你想想看，光伏板发了多少电、储能电池还剩多少、负载消耗了多少，这些数据如果只是躺在数据库里，那跟废纸没什么区别。只有把它们变成可视化的图表、跳动的数字、实时的曲线，才能真正帮我们做决策。
这一章，我们就来聊聊Grafana。嗯，我最早接触Grafana是在一个风电场的项目中，当时甲方要求大屏上同时展示风速、发电功率、设备温度等十几个指标。说实话，一开始我也踩了不少坑，比如数据刷新太慢、图表堆叠看不清、告警规则设得太敏感导致半夜被电话吵醒……这些经验，今天一并分享给你。
4.1 Grafana仪表盘设计：从数据到视觉
Grafana的仪表盘设计，说白了就是「搭积木」。每一块积木是一个Panel（面板），你可以把不同的Panel组合成一个Dashboard（仪表盘）。但怎么搭得好看、搭得有用，这里头有门道。
核心原则：仪表盘不是数据堆砌，而是决策辅助。每一块Panel都应该回答一个问题。
我在项目中习惯先画一个草图，把大屏分成几个区域：
- 顶部区域：展示全局KPI，比如总发电量、总负载、系统效率。用Stat或Gauge面板，数字要大、颜色要醒目。
- 中部区域：展示时间序列数据，比如光伏功率曲线、负载曲线。用Time series面板，可以叠加多条线。
- 底部区域：展示设备状态、告警列表、地理分布。用Table、Alert list、Geomap等面板。
举个例子，一个典型的光伏电站大屏，我会这样设计：
+--------------------------------------------------+
| 总发电量: 1234.5 kWh | 当前功率: 567.8 kW |
| 系统效率: 85.3% | 碳排放减少: 0.5 吨 |
+--------------------------------------------------+
| 光伏功率曲线 (过去24小时) |
| ████████████████████████████████████████████████ |
| 负载曲线 (过去24小时) |
| ████████████████████████████████████████████████ |
+--------------------------------------------------+
| 设备状态 | 告警列表 | 地理分布 |
| 逆变器1: 正常 | 警告: 温度过高 | [地图] |
| 逆变器2: 正常 | 信息: 维护提醒 | |
+--------------------------------------------------+这里要注意，颜色不要超过3种。我曾经见过一个大屏用了七八种颜色，看起来像彩虹，实际上根本分不清重点。我建议用绿色表示正常、黄色表示警告、红色表示故障，这是行业惯例，用户一看就懂。
4.2 实时数据流展示：让大屏「活」起来
静态的仪表盘没什么意思，真正有价值的是实时数据流。Grafana支持多种数据源，比如Prometheus、InfluxDB、MySQL等。对于绿色能源系统，我强烈推荐用Prometheus + Telegraf的组合。
为什么会这样？因为Prometheus的Pull模式非常适合监控场景，你不需要在每个设备上装Agent，只需要暴露一个/metrics端点就行。Telegraf则负责采集各种协议的数据，比如Modbus、MQTT、SNMP，然后推给Prometheus。
我记得有一次，客户要求大屏上的数据延迟不能超过5秒。我们一开始用MySQL做数据源，结果查询太慢，延迟到了30秒。后来换成InfluxDB，延迟直接降到1秒以内。所以，实时数据流一定要用时序数据库，别用关系型数据库硬扛。
配置实时刷新也很简单，在Grafana的Panel设置里，把「Refresh」时间改成5s或10s就行。但要注意，刷新频率越高，对数据库的压力越大。我一般建议：
| 场景 | 推荐刷新频率 | 说明 |
|---|---|---|
| 关键指标（功率、电压） | 5秒 | 需要快速响应 |
| 次要指标（温度、湿度） | 30秒 | 变化较慢 |
| 统计指标（日发电量） | 5分钟 | 不需要实时 |
另外，Grafana的变量（Variables）功能非常强大。你可以定义一个变量叫「site」，然后在下拉框里选择不同的电站。这样，一个仪表盘就能复用给多个站点，省去了重复配置的麻烦。
4.3 告警规则配置：别让大屏变成「摆设」
大屏上数据再好看，如果没人盯着，那也白搭。告警规则才是真正让系统「主动」工作的关键。Grafana的告警功能从8.0版本开始大改，现在用的是统一的告警引擎，支持多条件、多通知渠道。
避坑指南：我曾经在项目里配置了一条告警：「当光伏功率低于100kW时触发」。结果每天傍晚太阳下山，功率自然下降，告警就疯狂触发。后来我加了一个条件：功率低于100kW且持续超过10分钟，才触发告警。这样才避免了误报。
配置告警规则，我一般遵循这几个步骤：
- 定义指标：比如 `solar_power_kw`，这是你要监控的指标。
- 设置阈值：比如低于100kW或高于500kW。阈值可以是一个固定值，也可以是一个动态值（比如过去24小时的平均值）。
- 设置持续时间：比如持续5分钟。这能过滤掉瞬时的波动。
- 配置通知渠道：比如邮件、钉钉、企业微信、Slack等。
下面是一个实际的告警规则配置示例（使用Grafana的Alerting UI）：
规则名称: 光伏功率过低告警
条件:
- 查询: avg(solar_power_kw) < 100
- 持续时间: 5m
- 评估频率: 1m
通知渠道:
- 钉钉Webhook: https://oapi.dingtalk.com/robot/send?access_token=xxx
- 邮件: ops@example.com
消息模板:
- 标题: [严重] 光伏功率过低
- 内容: 电站 {{ .Labels.site }} 当前功率 {{ .Values.A }} kW，低于阈值100kW，请检查。这里有个小技巧：告警消息里一定要带上上下文信息。比如哪个电站、当前值是多少、阈值是多少。不然运维人员收到告警，还得去查半天才知道怎么回事。
4.4 实战案例：搭建一个光伏电站监控大屏
好了，理论说完了，我们动手搭一个。假设我们有一个光伏电站，数据已经通过Telegraf采集到了InfluxDB里。我们要在Grafana里创建一个仪表盘，包含以下内容：
- 顶部：总发电量、当前功率、系统效率
- 中部：光伏功率曲线（过去24小时）
- 底部：逆变器状态列表、告警列表
第一步，添加数据源。在Grafana的Configuration里，选择InfluxDB，填上地址、数据库名、用户名密码。测试连接，成功。
第二步，创建Dashboard。点击「+」→「Dashboard」→「Add new panel」。选择Time series，查询语句写：
SELECT mean("power") FROM "solar" WHERE $timeFilter GROUP BY time($__interval)第三步，配置Stat面板。新建一个Panel，选择Stat类型，查询总发电量：
SELECT last("total_energy") FROM "solar"第四步，添加告警。在光伏功率曲线Panel上，点击「Alert」→「Create alert rule」。设置条件：当功率低于100kW且持续5分钟时触发。通知渠道选钉钉。
第五步，调整布局。把Panel拖到合适的位置，调整大小。我习惯把Stat面板放在顶部，Time series放在中间，Table放在底部。最后点击「Save」，给仪表盘起个名字，比如「光伏电站监控大屏」。
提示：Grafana支持导出仪表盘的JSON配置。你可以把配置保存到Git仓库里，方便版本管理和团队协作。我每次做完一个仪表盘，都会导出一份JSON，放到项目的docs目录下。
4.5 知识体系总览
为了让你更直观地理解这一章的内容，我画了一张图。它展示了从数据采集到可视化展示的完整链路，以及告警规则在整个流程中的位置。
从这张图你可以看到，整个系统分为三层：数据采集层负责从设备获取数据，数据存储层负责持久化，可视化层负责展示。告警引擎是一个独立的模块，它从存储层拉取数据，根据规则判断是否需要通知用户。嗯，这个架构我在好几个项目里都用过，稳定可靠。
好了，这一章的内容就到这里。Grafana的功能远不止这些，比如还有Annotations（注解）、Templating（模板）、Permissions（权限）等高级功能。但掌握了仪表盘设计、实时数据流和告警规则配置，你已经能搭建一个可用的监控大屏了。剩下的，就是在实际项目中慢慢摸索了。