菜单
Enterprise Open source

升级自托管 Grafana 实例的策略

在 Grafana Labs,我们信奉尽早频繁地发布功能,近年来我们更加坚定地遵循这一理念。

我们不再等待年度主要版本才为您提供下一个重要改进。相反,我们全年定期为自托管用户(Grafana OSSGrafana Enterprise)提供新功能、错误修复和安全补丁。

可靠的发布流程为您这样的用户提供了最佳的 Grafana 体验,并提供了以最适合您和您的组织的方式进行升级的灵活性。

注意

Grafana Cloud 遵循与 Grafana OSS 和 Enterprise 不同的发布节奏。在 Cloud 中,Grafana 使用滚动发布渠道。要了解有关发布渠道的更多信息,请参阅Grafana Cloud 的滚动发布渠道

每种发布类型预期包含的内容

我们将 Grafana OSS 和 Grafana Enterprise 发布分为三个主要类别

  • 次要版本(每隔一月):这些版本可能包含新功能、废弃通知、即将发布的破坏性变更通知、先前已公布的破坏性变更、错误修复和安全漏洞补丁。
  • 主要版本(每年一次,四月/五月):这些版本类似于次要版本,但会伴随 GrafanaCON 并提供全面的升级指南,适用于喜欢每年只升级一次的用户。
  • 补丁版本(每月):这些版本包含对当前支持版本的错误修复以及任何安全漏洞补丁。

您可以选择自己的节奏:对于频繁的自托管更新,您应该遵循次要版本(例如,从 11.1 升级到 11.2),这也会让您获得最新的功能。如果您需要更长时间来审查我们的新版本,则应遵循主要版本。这两种策略都会获得包含安全修复的补丁版本(高严重性安全修复也会导致临时补丁发布)。我们将在本指南后面提供关于升级节奏的更多指导。

如何查找特定版本的详细信息

我们乐于与您分享所有优秀的功能,以便您充分利用 Grafana。我们也理解完整的版本文档可以帮助您自信地进行升级。无论是了解某个错误是否已修复、某个安全漏洞是否已打补丁,还是了解如何缓解破坏性变更的影响,适当的文档都能帮助您就何时升级本地 Grafana 实例做出明智的决定。

我们在多个位置提供版本文档,以满足不同的需求

  • 最新动态 概述了每个主要版本和次要版本中首次亮相的新功能。
  • 破坏性变更 通知您主要版本中包含的、可能影响您的更新,并在需要时提供缓解建议。
  • 升级指南 指导您如何升级到较新的次要版本或主要版本。
  • 最后,每个版本(主要、次要、补丁、安全)都会生成一份 变更日志,概述了该版本中包含的所有变更。

发布预期时间

目前,Grafana 采用月度发布周期。以下是 2025 年上半年预定的发布计划

预计发布日期Grafana 版本发布类型
2025年1月28日11.5 和支持版本次要和补丁
2025年2月18日支持版本补丁
2025年3月25日11.6 和支持版本次要和补丁
2025年4月15日支持版本补丁
2025年5月5日Grafana 12.0 和支持版本主要和补丁

几点重要说明

  • 上述计划概述了我们如何规划发布日期。但是, unforeseen events and circumstances 可能导致日期变更。
  • 高严重性安全事件和功能退化事件将导致未提前计划的临时发布。
  • 补丁发布适用于当前(最新发布)的 Grafana 次要版本。如果存在需要修补的关键错误或安全漏洞,可能会包含其他较旧的 Grafana 版本。
  • 发布冻结期:Grafana 每年会实施两次发布冻结期,以适应假期季,具体日期将在假期季临近时公布。在此期间,不会执行任何预定发布。但是,这不适用于在运营或安全事件过程中可能需要的变更。

Grafana 安全发行版:改进的版本命名约定

我们改进了安全版本发布的命名约定,以便更容易地将安全版本与标准补丁版本区分开来。

过去,关键漏洞会触发非计划发布,这些发布会增加补丁版本(例如,从 10.3.0 到 10.3.1)。然而,我们发现这些版本的命名约定并未明确传达更新的性质。例如,如果版本从 11.3.0 变为 11.3.1,没有迹象表明这是安全修复、错误修复还是次要功能更新。这种缺乏明确性导致了对更新的紧迫性和性质的困惑。

注意

Docker 不允许镜像标签名中使用加号 (+)。在 Docker 标签中,加号 (+) 将被渲染为破折号 (-)。

我们新的方法直接解决了这个问题。今后,安全发布版本将附加“+security”来表明该版本是指定版本加上安全修复。

例如:一个名为“11.2.3+security-01”的版本将包含 11.2.3 中发布的内容以及指定安全修复。一旦发布,该安全修复也将自动包含在受影响版本的所有未来发布中。

这种命名约定应有助于更容易地识别安全更新及其所基于的 Grafana 版本,从而更好地理解每个版本的重要性和紧迫性。

关于版本支持的须知事项

自托管 Grafana 用户可以控制何时升级到新版本。为了帮助您就是否升级做出明智的决定,了解当前版本的支持级别非常重要。

对于自托管 Grafana(包括 Enterprise 和 OSS),版本的支持情况如下

  • 每个次要版本的支持期限为发布日期后九个月。
  • 主要版本的最后一个次要版本的支持将额外延长六个月,总共在发布日期后提供 15 个月的支持。

以下是到 2025 年预计版本支持的概览

版本发布日期支持生命周期结束 (EOL)
10.4 (10.x 的最后一个次要版本)2024年3月2025年6月(扩展支持)
11.0五月 2024自 2025 年 2 月起不再支持
11.1六月 2024自 2025 年 3 月起不再支持
11.2八月 2024五月 2025
11.3十月 2024七月 2025
11.4十二月 2024九月 2025
11.5一月 2025十月 2025
11.6(11 的最后一个小版本)三月 2025六月 2026
12.0五月 2025一月 2026

这些版本如何获得支持?

随着新版本 Grafana 的发布,支持级别会发生变化。以下是一些需要记住的详细信息:

  • 当前(最新发布)版本的 Grafana 获得最高级别的支持。此版本的发布包含所有新功能和所有错误修复。
  • 所有受支持的版本都会收到针对影响该版本的漏洞的安全补丁。
  • 所有受支持的版本都会收到针对导致关键功能退化事件的错误的补丁。

考虑到所有这些,想要获得最新功能和所有错误修复的用户应使用当前(最新发布)版本的 Grafana。

什么是关键功能退化?

关键功能退化通常符合以下标准之一:

  • 主要功能普遍不可用(例如,无法创建仪表盘,无法进行身份验证)。
  • 对大量客户产生重大(关键)影响。
  • 针对一个或多个客户的重大升级事件。

自我管理的升级策略

根据您的需求,选择最适合您的升级策略。以下是在实践中可能的样子:

策略/节奏优点/缺点示例升级流程
小版本 / 每两月一次 (11.1 到 11.2)我们的推荐策略。它将最新的、安全的发布版本与及时访问最新功能结合在一起。
  • 需要审查的变更日志较小
  • 与活跃维护的插件兼容性最高
  • 轻松迁移到 Grafana Cloud
  • 2025 年 1 月:您审查 11.5 变更日志并将该版本部署到测试环境
  • 2025 年 2 月:您将 11.5 部署到生产环境
  • 2025 年 3 月:发布 11.6
主要版本 / 每年一次 (10.0 到 11.0)年度升级路径,仍然可以访问 GrafanaCON 上展示的最新功能。
  • 需要审查的变更日志较大
  • 与插件兼容性高
  • 相对轻松地迁移到 Grafana Cloud
  • 2024 年 5 月:发布 11.0,您开始进行大型变更日志审查
  • 2024 年 6 月:您将 11.0 部署到测试环境
  • 2024 年 7 月:您将 11.0 部署到生产环境
  • 2025 年 5 月:发布 12.0
上一个主要版本 / 每年一次 (10.4 到 11.6)具有延长支持时间线的发布版本
  • 与活跃开发的插件兼容性有限
  • 需要审查的变更日志较大
  • 迁移到 Grafana Cloud 可能需要专业支持
  • 2025 年 5 月:发布 12.0,标记前一个次要版本 (11.6.x) 为延长支持版本,您开始进行大型变更日志审查 (10.4.x 到 11.6.x)
  • 2025 年 6 月:您将 11.6.x 部署到测试环境
  • 2025 年 7 月:您将 11.6.x 部署到生产环境

遵循“小版本”策略以获得最大的灵活性,您也可以偶尔将节奏延长至整个季度,并且仍然可以依赖当前部署的小版本获得安全修复支持。

Grafana 团队如何在发布过程中捕获错误和问题

  1. 每个团队都为其代码编写自动化测试,并且我们运行 自动化测试,包括单元测试、集成测试、端到端测试和负载测试。特别是对于插件,我们测试数据源的前端和后端部分(单元)、将数据源与 Grafana 版本矩阵集成(E2E),以及数据源与其调用的 API 之间的契约(集成)。
  2. 我们通过部署到内部可观察性堆栈对新功能进行内部手动验收和冒烟测试。之后,我们在 Grafana Cloud 中逐步推出,然后发布 OSS 和企业版。每个阶段都会捕获错误。
  3. 我们在实验性或私有预览 发布阶段 推出新功能,这些功能由特性开关控制。这有助于我们在开发过程中改进功能。如果您有兴趣提前体验功能(包括在您的开发或测试环境中),请告知我们。
  4. 我们持续扫描 Grafana、所有插件及其依赖项是否存在安全漏洞。

最大程度地减少升级过程中出现错误和问题的可能性

尽管进行了全面测试,您在升级时仍可能遇到问题

错误

错误是版本中代码更改导致的意外副作用,会引起问题。有些错误会影响所有用户,我们通常在测试的早期阶段捕获这些错误。其他错误则发生在具有特定配置或不常见用例的少数 Grafana 实例中;例如,特定的身份验证设置或特性开关组合。Grafana 插件还通过 API 与外部服务交互以查询数据,有时这些 API 会在未通知的情况下发生更改,从而导致依赖这些数据源的仪表盘出现问题。Grafana Labs 部署了监控来定期测试这些 API,但有时它们会以意想不到的方式中断。

通过保持最新状态并在生产环境之前在开发或测试环境中推出升级来降低错误风险。Grafana 企业版许可证允许您为此目的获得一个额外的开发和测试实例,可通过您的客户团队获取;在 Grafana Cloud 中,您可以使用 滚动发布渠道 创建在生产环境之前升级的开发和测试堆栈。

  • 定期备份您的数据库,尤其是在升级之前。
  • 如果在开发或测试环境中遇到问题,请回滚并报告问题。
  • 在 Cloud 中,在 fast 渠道上运行开发或测试堆栈,并在 steadyslow 渠道上运行生产堆栈。要更改您的发布渠道,请提交支持工单。

已知破坏性更改

通常,我们始终追求向后兼容性和迁移,并将破坏性更改保留在 Grafana 的每年一次主要发布版本中。但偶尔也会在次要版本中包含小的破坏性更改(例如 API 负载的更新)。这些更改会在升级指南新功能以及我们的变更日志中宣布。

升级之前,请务必阅读升级指南变更日志,了解并考虑破坏性更改。

插件不兼容

Grafana Core 以单个二进制文件形式发布,包含仪表盘、告警、探索、认证和授权、报告、一些核心数据源以及其他组件。然而,几乎所有使用 Grafana 的人都还会使用插件:面板、数据源和独立于 Grafana 发布的应用程序。每个插件版本都列出了其 Grafana 版本依赖项(您可以在 https://grafana.org.cn/grafana/plugins/ 查看),但不同插件的不同版本也可能相互作用——例如,您可以在 Grafana 的一个面板中可视化来自某个数据源的数据,这三者都是独立于彼此进行版本控制的。这可能会导致在测试中难以捕获的问题。

为了最大程度地减少插件不兼容问题的可能性,请运行最新版本的插件并定期更新。始终在更新 Grafana 之前更新插件。插件也遵循 Semver(语义化版本控制)模式,因此在升级到该插件的新主要版本之前,请查看插件的变更日志以了解破坏性更改。