KechuAI

Perses：不做"更好的 Grafana"，而是给仪表盘一个开放规范

可观测性
Grafana
开源
监控
CNCF
Dashboard
2026/9/29
·

阅读时间: 大约 10 分钟

Perses：不做”更好的 Grafana”，而是给仪表盘一个开放规范

Perses 平台概览（官方首页 GIF）

谈到可观测仪表盘，几乎所有人第一反应是 Grafana。但 Grafana 的仪表盘 JSON 事实上是一套私有格式——你能看、能改，却没有一个公开、稳定、跨工具的 schema 来约束它。Perses 的野心不是”做一个更好看的 Grafana”，而是用一个公开规范（open specification）来替换这套私有格式，并围绕它建一套 Dashboard-as-Code 的工具链。官网当前版本 v0.54.0（约 2.5k star、251 位贡献者），属于 CNCF 生态项目，背后有 Amadeus、Chronosphere、RedHat、SAP 等采用方。本文基于 perses.dev 官方文档，做一次拆解。

一、背景动机：仪表盘需要”代码化”与”开放规范”

Grafana 统治力强，但它的仪表盘 JSON 是事实上的私有格式：没有公开 schema、没有静态校验、迁移和 lint 都很痛。当团队把仪表盘也纳入 GitOps（Dashboard-as-Code），就需要一个可被版本控制、可在 CI 里校验、可被多工具互操作的规范。Perses 切的就是这个缺口。

Koala 点评点得很准：它的重点不在”更好的 Grafana”，而在开放规范——用公开 schema 替换 Grafana 的私有 JSON，并且提供 Grafana 迁移工具。

二、是什么：一个开放的仪表盘规范 + 可嵌入的可视化组件

Perses 的自我定位是 “An open specification for dashboards. The open dashboard tool for Prometheus and other data sources.” 它同时提供：

  • 可视化平台：监控、链路、日志、Profiling 一屏看；
  • 可嵌入组件：面板以 npm 包形式嵌入你自己的应用；
  • DevOps 友好：percli CLI、Dashboard-as-Code、静态校验；
  • Kubernetes 原生：Operator 把仪表盘当 CRD 管；
  • 插件化：数据源与面板都可插拔。

原生支持的数据源覆盖了整个云原生可观测栈：Prometheus（指标）、Tempo（链路）、Loki（日志）、Pyroscope（Profiling），以及 ClickHouse、GreptimeDB、OpenSearch、VictoriaLogs。面板类型包括时间序列、柱状、饼图、状态历史、火焰图、追踪甘特、日志表等十几种。

三、技术机制：开放 schema + CUE/Go SDK + percli

  • 开放规范：仪表盘被定义成一份公开 schema。官网的 open-spec 图展示了 DashboardSpec 结构体——Display、Datasources、Variables、Panels、Layouts、Duration、RefreshInterval 等字段都是显式、可机器校验的。
  • Dashboard-as-Code：官方提供 CUE SDK 与 Go SDK，让你用代码而非拖拽定义面板。
  • percli CLI：接进 CI/CD，做静态校验与自定义 lint 规则（Custom Lint Rules）。
  • K8s Operator：仪表盘作为 CRD 管理，配合 ConfigMaps / OCI Artifacts 分发。
  • 插件生态：数据源与面板都是插件，UI 组件可嵌入自有产品。
  • Grafana 迁移：提供从 Grafana 导入的工具（Migrate from Grafana）。
  • 内置 PromQL 调试器与指标浏览器，以及数据源自动发现（Datasource discovery）。

Perses 开放规范：DashboardSpec 结构体定义（官方）

四、关键事实表

项目官方口径
定位开放规范的开源仪表盘工具
当前版本v0.54.0
生态归属CNCF
原生数据源Prometheus / Tempo / Loki / Pyroscope / ClickHouse / GreptimeDB / OpenSearch / VictoriaLogs
Dashboard-as-CodeCUE SDK + Go SDK
CLIpercli（静态校验、自定义 lint）
K8sOperator（仪表盘 CRD）
组件分发npm 插件，可嵌入自有应用
迁移提供 Grafana 导入工具
主要采用方Amadeus、Chronosphere、RedHat、SAP 等

五、口径偏差与成熟度局限

  1. 仍是 v0.x，API 与 UI 未冻结。版本号停在 v0.54.0，意味着核心 API、插件模型仍可能变动；生产重度押注前要评估升级成本。
  2. “开放规范”是目标，不是已被广泛采纳的标准。它确实用公开 schema 替代了 Grafana 私有 JSON，但要成为 Grafana 那种”事实标准”，还需要更多工具与厂商围绕该规范建设。当前它更多是”一个有野心的替代”，而非”已经赢了格式之争”。
  3. Grafana 迁移是工具，不是无痛。官方提供导入器，但 Grafana 庞大的面板生态、数据源插件、企业功能，不可能 100% 平移。迁移前要在自己的仪表盘上验证覆盖率。
  4. 功能广度仍在追赶 Grafana。Grafana 积累了十几年的面板、数据源、企业级 SSO/告警/报表，Perses 在面板类型与生态数量上仍有差距（虽已覆盖主流可观测场景）。
  5. 插件模型意味着部分能力在插件里。某些数据源/面板需要单独加载插件，开箱体验不如 Grafana 全家桶。

六、适用 / 不适用场景

适合：

  • 已经标准化使用 Prometheus/Tempo/Loki/Pyroscope、想要 Dashboard-as-Code + GitOps 的团队；
  • 想把监控面板嵌入自有产品（可嵌入 npm 组件）的工程团队；
  • 受够 Grafana 私有 JSON、想要可静态校验、可 lint 的仪表盘定义的平台团队；
  • K8s 环境里想把仪表盘当 CRD 管理的 GitOps 实践者。

不适用：

  • 现在就要最广的面板/数据源插件生态与企业级功能——Grafana 仍更全；
  • 想要一个稳定不变 API 的 v1.0 产品——它还在 v0.x；
  • 仅做简单图表、不想引入新运维负担的小团队。

七、客观分析：优势与意义

优势： 开放 schema 解决了 Grafana 私有 JSON 的痛点、Dashboard-as-Code 原生支持、K8s Operator 与 percli 契合 GitOps、可嵌入组件、覆盖主流云原生可观测数据源、CNCF 背书。

局限： v0.x 未冻结、规范尚未成为行业标准、面板生态仍在追赶 Grafana、Grafana 迁移非无痛、部分能力靠插件。

它意味着什么： Perses 是”可观测性基础设施标准化”这股力量的代表——和 OpenTelemetry 试图统一遥测数据格式一样，Perses 试图统一仪表盘这一层的格式。它的价值不在于今天立刻替换 Grafana，而在于提供了一个”仪表盘也能像代码一样被校验、review、版本化”的开放方向。对已经重度 GitOps 化、又被 Grafana JSON 束缚的平台团队，Perses 值得现在就放进技术雷达持续跟踪；但在它走到 v1.0、迁移工具更成熟之前，把 Grafana 整个换掉仍为时过早。

参考来源