2. Grafana 基础回顾：架构、数据源、仪表盘与告警核心概念
在深入云原生日志平台的变更门禁与准入策略之前，必须重新夯实 Grafana 的核心知识体系。本章从架构分层、数据源接入、仪表盘构建到告警引擎，梳理出后续章节依赖的四个关键支柱。
2.1 Grafana 整体架构
Grafana 采用前后端分离的插件化架构，核心组件包括前端 UI、后端 API 服务器、告警引擎、以及可选的数据库（SQLite/PostgreSQL）用于存储仪表盘、用户和配置。数据不经过 Grafana 持久化，仅通过数据源插件实时查询。
架构要点： Grafana 本身不存储时序数据，所有可视化与告警均依赖后端数据源插件的查询能力。这一设计使其成为“可观测性统一入口”，但也意味着数据源可用性与查询性能直接影响仪表盘与告警的可靠性。
2.2 数据源：Grafana 的“感官”
数据源是 Grafana 连接外部系统的桥梁。每个数据源对应一个插件，定义了查询语言、传输协议和返回格式。在云原生日志平台场景中，最核心的数据源是 Loki（日志）和 Prometheus（指标）。
| 数据源类型 | 查询语言 | 典型用途 | 变更门禁关注点 |
|---|---|---|---|
| Prometheus | PromQL | 指标监控、告警规则评估 | 指标查询延迟、数据断点 |
| Loki | LogQL | 日志聚合、审计追溯 | 日志索引效率、标签基数 |
| Elasticsearch | ES DSL / Lucene | 全文搜索、结构化日志 | 分片健康、查询超时 |
| InfluxDB | Flux / InfluxQL | 事件型时序数据 | 写入吞吐、保留策略 |
实践提示： 在变更门禁场景中，建议为每个数据源配置独立的健康检查探针，并在仪表盘顶部添加“数据源状态”面板。当数据源不可用时，自动暂停依赖该数据源的告警规则，避免误报。
2.3 仪表盘：可视化编排与变量驱动
仪表盘是 Grafana 最直观的交互界面。一个生产级仪表盘通常包含：
- 面板（Panel）：可视化单元，支持图表、表格、日志、统计等类型。
- 行（Row）：面板的逻辑分组，用于组织同类指标。
- 变量（Variable）：动态筛选器，支持查询、自定义、间隔等类型，实现交互式下钻。
- 模板化（Templating）：通过变量复用仪表盘，适配不同环境（开发/预发/生产）。
2.4 告警：从规则到通知的完整链路
Grafana 告警引擎（Grafana Alerting）是统一告警管理的核心。在变更门禁场景中，告警规则直接用于检测变更后的异常状态。告警链路包含以下关键阶段：
- 告警规则（Alert Rule）：定义查询表达式、评估频率、条件阈值。
- 评估（Evaluation）：引擎按周期执行查询，判断是否触发。
- 状态（State）：Normal / Pending / Firing / Resolved。
- 沉默/静默（Silence）：在变更窗口内抑制已知告警，避免噪音。
- 通知（Notification）：通过联系点（Contact Point）发送到钉钉、Slack、PagerDuty 等。
变更门禁关键约束： 告警规则的评估延迟必须小于变更门禁的“健康检查超时时间”。例如，如果门禁等待 5 分钟，告警评估间隔应 ≤ 1 分钟，且至少包含 3 个连续评估周期，才能可靠判断变更是否引入问题。
| 告警组件 | 作用 | 变更门禁中的角色 |
|---|---|---|
| Alert Rule | 定义触发条件 | 检测变更后指标/日志异常 |
| Evaluation Group | 规则分组与评估调度 | 控制评估频率，避免门禁等待过长 |
| Silence | 临时静音告警 | 变更窗口内屏蔽已知告警，聚焦新异常 |
| Contact Point | 通知渠道配置 | 将变更告警发送到 SRE 值班群 |
| Notification Policy | 路由与重复策略 | 确保变更告警不被降级或淹没 |
回顾总结： Grafana 的架构决定了它作为“可观测性控制面”的定位。数据源提供实时数据，仪表盘提供可视化交互，告警引擎提供自动化检测。在后续章节中，我们将基于这三个能力构建变更门禁准入策略——通过仪表盘展示变更影响，通过告警规则驱动门禁决策，通过数据源健康检查确保门禁判断的准确性。