GitOps 管理 Prometheus 的最佳实践 — 内含 Git Server 配置指南

Prometheus 可以说是可观测领域的事实标准了，配置文件和规则文件的管理，有时可能会因以下问题而感到困扰：

1.语法错误，规则验证：错误的语法可能会引发一些预期之外的行为。这需要仔细地进行测试和验证，以避免产生错误报警。

2.文件版本，撤销操作：如果不能方便地回退文件的更改，会消耗用户大量精力去查找历史版本。

3.合作不力：运维人员不知道他们与其他人是否拥有完全相同的配置文件。

4.规则可视化：除非用户明确地从 Prometheus 查询数据，否则他们不知道规则会对指标产生怎样的影响。

了解到这些挑战之后，我们需要一个能够解决上述问题的系统。对于问题 #1，#2 和 #3，用 GitOps理念来管理再适合不过了，而针对 #4，我们需要编辑规则可以实时看到数据的系统。

Git 是什么

Git，作为一个免费且开源的分布式版本控制系统，深受软件开发者和程序员的推崇，其主要的优势包括：

分布式版本控制：在这种模式下，每个开发者都拥有项目仓库的全部副本，这使得他们可以离线或独立地进行工作。
高效性能：Git 运行速度快，能轻松处理大规模项目和详细的历史记录。
无缝协作：Git 通过提供诸如远程仓库、拉取请求和代码审查等功能，使得团队协作更加简单顺畅。
强大的撤销和版本控制功能：Git 使得用户能够轻松撤销修改，同时，也可以方便地找回历史文件。
跨平台兼容：Git 拥有众多的跨平台客户端，使得不同操作系统的用户都能方便地使用它。

而 GitOps 则是一种新兴的工作理念，它将基于 Git 的工作流程延伸到了基础设施配置上。这也就意味着在应用的全生命周期内，每一次的更改都会被记录在 Git 仓库中，从而实现完整的审计跟踪。

GreptimeCloud 提供 Git 管理 Prometheus 规则文件

GreptimeCloud，一个云原生的时序数据管理平台，采用了 GitOps 理念，使用 Git 作为 CRUD API 来管理用户的 Prometheus 规则文件。由于 Git 具有上文中提到的诸多优点，且广泛地被开发者接受，使其成为规则管理完美的解决方案。

那么，GreptimeCloud 是如何处理 Prometheus 规则文件呢？

以 GitOps 方式管理 Prometheus 规则

在 GreptimeCloud 中创建一个服务意味着在特定区域启动一个数据库实例。创建此服务后，你将获得一个相应的 Git 仓库，用来管理你的 Prometheus 配置文件，如 prometheus.yml，以及警报/记录规则文件。

你可以像操作任何 Git 仓库一样与此仓库进行交互。将仓库克隆到你的本地系统，修改你的规则文件，提交这些更改，并将更新的文件推回到远程仓库。服务器端的 Hook 脚本可以验证你的规则文件是否存在基本的语法问题。

一旦你成功推送规则文件，GreptimeCloud Prometheus Workbench 会将所有规则文件与从 Prometheus 远程写入的数据组合起来，生成仪表盘。更进一步，你可以直接在 GreptimeCloud Web 中编辑规则文件，仪表板将实时更新。此外，你还可以通过 git pull 或 git fetch 来将这些更改同步到你的本地副本。

如果正确地配置了 AlertManager 或 Slack Webhook 的话，一旦报警规则匹配，那么报警将会被发送到你的 AlertManager 或者 Slack频道中。

此外，你还可以将规则导出为 Grafana 适用的 JSON 格式，然后直接将这些 JSON 文件导入到你的 Grafana 实例中。未来，我们计划提供一个 Dashboard as Code 的解决方案，提供声明式地管理 Grafana Dashboard 的方案，使数据的可视化更符合 GitOps 理念。

在自有服务器上使用 Git 工作流

既然 GreptimeCloud 使用了 GitOps 进行规则管理，你可能会对我们如何实施 GitOps 工作流程感到好奇。同时，处于安全性、控制力考虑，很多用户会有使用 Git 操作来管理自己配置文件的需求。

为了帮助你建立自己的 Git 服务器，并有效地利用 Git 操作的全部能力，下文中将分享我们的服务器设置方法提供参考。

Git HTTP Server 设置

在 C/S 架构中，服务器负责存储代码仓库，而客户端则与该服务器交互，执行各种操作。而在实际操作上，配置一个 Git 服务器并不复杂。Git 通过 HTTP 通信有两种模式，在 Git 1.6.6 版本之后，引入的 Smart HTTP 协议能够让 Git 可以像通过 SSH 那样智能的协商和传输数据，它运行在标准的 HTTP/s 端口上并且可以使用各种 HTTP 验证机制。

设置 Smart HTTP 一般只需要在服务器上启用一个 Git 自带的名为 git-http-backend 的 CGI 脚本，它被引用来处理协商通过 HTTP 发送和接收的数据。它本身并不包含任何授权功能，但是授权功能可以在 Web 服务器层引用它时被轻松实现。你可以在任何可以处理 CGI 的 Web 服务器上办到这点，比如 Apache 或 Nginx。

如果你想要通过流行的编程语言来设置 Git 服务器的话，也并不复杂。你可以参考 asim/git-http-backend 来获取一些启发，非常简单易懂。最常用的路径是 /git-upload-pack，/git-receive-pack 和 /info/refs，它们能处理像 clone, pull, fetch, push 等 Git 操作。同时，你还可以自定义访问控制机制来确保仓库内容安全。

当你的 Git 服务器配置完成后，如何定制业务逻辑来满足自己的工作流程呢？

和其它版本控制系统一样，Git 能在特定的动作发生时触发自定义 Hook 脚本。客户端 Hook 脚本由诸如 commit， merge 这样的操作所触发，而服务器端 Hook 脚本作用于诸如接收通过网络执行的提交操作，用户可以按自己的需求来配置。服务器端 Hook 包括 pre-receive，update 和 post-receive，你可以利用任何服务器端 Hook 脚本来为你的项目执行几乎任何类型的策略，比如触发 HTTP 请求，将数据存入数据库，发布事件到消息队列等。Pre-receive Hook 可以以非零值退出，这样所有的推送内容都不会被接受，并给客户端返回错误消息。

现在，你的 Git 服务器已经准备好为 Git 操作服务了，像克隆仓库，添加配置文件，以及提交并推送到远程服务器的操作将触发服务器端的 Hook 脚本，更好的实现 CI/CD 工作理念。