GreptimeDB 监控自举 | 如何用 GreptimeDB 监控 GreptimeDB

自监控的悖论

当使用 GreptimeDB 作为其时序存储后端的时候，我们需要对 GreptimeDB 自身进行监控（我们可以将这种类型的监控称为元监控）。这样一来就会碰到一个「悖论」：明明自己就是一个时序数据库，但总是需要：

安装 Prometheus 来监控 GreptimeDB 的 Metrics；
安装 Loki 或其他日志组件来监控 GreptimeDB 的日志；
安装 Jaeger 或其他 Tracing 服务来监控 GreptimeDB 的 Tracing；

也就是说，尽管 GreptimeDB 是一个功能强大的时序数据库，居然还需要再安装 2-3 个其他同类型的时序数据库对自己进行监控。虽然这种悖论在当今的可观测技术栈里比较常见，但我们认为一个好的时序数据库要能实现监控自举：能否用同样的时序数据库启动自监控。

仔细思考这个悖论，其本质问题就是：你是不是一个可同时具备存储和计算多种时序类型（Metrics、Logs 和 Traces）的数据库？一旦时序数据库具备这一能力，我们其实就很容易实现监控自举。

经过一段时间迭代开发，GreptimeDB 已经初步实现了监控自举，我们可以很轻松地用 GreptimeDB 来监控 GreptimeDB 大部分监控数据。

监控自举的好处

监控自举有如下以下几个好处：

同构：这应该是监控自举最大的好处。技术栈的同构可以大幅降低运维成本。用户不再需要再不同类型的监控部署不同类型的时序数据库，所有的监控技术栈都将得到统一；
多种时序数据类型的存储和融合查询：用户可以在同一条 SQL 语句中同时联合查询多种数据类型，从而让 GreptimeDB 的 Troubleshooting 变得更加简单；
更节约监控资源：我们只需要 1 个核心数据库（大多数时候 Standalone 版本足矣）就可以满足对 GreptimeDB 的监控需求，无需额外部署其他类型的数据库，从而节约更多的 CPU 和 Memory 资源；

监控自举方案首先用在了 GreptimeDB Enterprise 的 Dashboard 中，并同时在 GreptimeDB Operator 开源了 Cluster 模式的监控自举，用户仅需要在对应 GreptimeDB 的 K8s CR 中做极少量的配置，便可以很容易地启动自监控模式并同时获取 Metrics 和 logs（Tracing 功能尽情期待 GreptimeDB 后续的开源实现）。

结合我们提供的 Grafana Dashboard，用户可以用同一套技术栈“开箱即用”一个完备的可观测方案（感兴趣的读者请阅读我们集群版本的「快速开始」文档）。而在 GreptimeDB Enterprise Dashboard 中，我们不仅具备 Grafana Dashboard 同时查看 Metrics 和 Logs 的功能，还致力于探索将二者融合查询来提供更高阶的自动诊断能力。

如何实现

鉴于 GreptimeDB 底层设计已经融合了 Metrics 和 Logs，因此我们本质上已经拥有了一个可同时存储 Metrics 和 Logs 的时序数据库。这样一来就解决了最核心的数据存储和计算的问题。

如何采集数据？
如何与 GreptimeDB Operator 进行融合？

第一个问题非常好回答，目前社区已经有一个与我们理念相同的高性能 Agent Vector。

感兴趣的读者可以阅读往期 Vector 系列文章（敬请期待更多 Vector 专题文章）：
《利用 Vector 将 Kafka 中的日志数据高效写入 GreptimeDB》
《实战 Vector：开源日志和指标采集工具》

当我们安装完一个 Vector，就可以同时收集多种不同类型的监控数据。这样一来，用户再也不需要专门为不同类型的监控数据部署不同类型的采集器。在 K8s 中，Vector 不仅可以以资源最优的 DaemonSet 模式部署，还可以用灵活的 Sideacar 模式进行部署。

第二个问题则是一个典型的部署问题。我们希望給广大开发者一种最自然的使用体验，而不是在 Helm Chart 中依赖一堆其他难以维护的 Chart，因此我们在 GreptimeDBCluster CRD 中增加了一个 monitoring 字段。用户可以在其对应的 GreptimeDBCluster CR 中加上如下配置：

yaml

apiVersion: greptime.io/v1alpha1
kind: GreptimeDBCluster
...
spec:
...
  monitoring:
    enabled: true
...

马上就能启动 GreptimeDB 自监控！

此时 GreptimeDB Operator 将会：

部署 Standalone 模式的 GreptimeDB 来监控 GreptimeDB 集群
尽管可以把 GreptimeDB 的监控数据写入到 GreptimeDB 自身，但我们并不希望对元监控的写入和查询会影响真实的监控业务。出于对资源隔离的原因，我们并没有采用这种模式。对于大多数类型的 GreptimeDB 集群，启动一个 Standalone 模式的 GreptimeDB 来进行监控不仅够用，而且还可以简化部署和降低运维成本。
部署 Vector Sidecar 来同时收集 Metrics 和 Logs
Operator 会在每一个 GreptimeDB Cluster 的 Pod 内部部署一个高性能且资源占用极低的 Vector Sidecar，用以收集 GreptimeDB 集群的 Metrics 和 Logs（也包括慢查询日志），并写入到 Standalone 实例中。

虽说 Sidecar 模式会占用对应 Pod 相应资源并可能会引入潜在的稳定性问题，但在中小规模集群场景中，这部分较低的性能消耗带来的则是部署的灵活性：我们可以在大多数场景都可以直接部署。对性能更为敏感的场景，我们则可以采用权限更高的 DaemonSet 模式来部署 Vector 服务。

为了更好地给用户提供“开箱即用”的能力，我们官方的 Helm Chart 针对这一特性支持了对 Grafana 的部署，当用户启动 grafana.enabled=true 时，会同时部署一个 Grafana 实例并自动配置数据源和 Dashboard，一键完成所有的部署。

有兴趣的读者可阅读这篇快速开始文档来体验这一过程。

这样一来，用户不仅成功部署了 GreptimeDB 集群，同时“开箱即用”地部署了对 GreptimeDB 集群的监控，这两套系统彼此隔离，互不干扰。

更进一步

细心的读者不禁会有疑惑：那么谁来监控这个 Standalone 模式的 GreptimeDB ？关于这个问题，一个比较简单的方式则还是利用自监控来解决，即：将自己的监控数据写入自身存储，并利用自身的计算能力进行查询。

可以在元监控中这么做的原因是：

元监控自身对于资源隔离要求比较低：我们可以容忍用同一个实例查询自身监控所带来的性能开销。这部分开销并不会真正影响元监控所正在监控的业务；
规模较小：元监控的监控数据量小，对其监控数据的查询也相对简单，自监控完全够用；

但严肃来看，这也并不是一种最好的做法，因为一旦元监控自身发生故障，这种做法也将失效。一种可选的模式则是选用具有独立故障域的监控服务来监控元监控服务，比如我们可以选用公有云的监控服务来监控我们的元监控服务。

关于这部分能力我们还在实现中，敬请期待。

未来计划

GreptimeDB 的监控自举其实是对 GreptimeDB + Vector 这套技术组合在时序数据融合存储和计算方面的小试牛刀。未来我们计划：

将 Vector 的运维流程融入到 GreptimeDB Operator 中，从而让用户在使用 GreptimeDB 的同时，也能很容易地运维 Vector；
更进一步探索时序数据的融合存储和计算。类似于 Prometheus Operator CRD （其实本质上就是 API）为例，我们其实可以定义出更具时序融合形态的模型，用户可以在这套模型中实现：
- 采集数据（比如基于 Pod Selector 或者 Service Selector 等）；
- 对数据进行预处理；
- 存储控制数据；
- 等等。

在这套统一的模型中，用户只需要关注监控数据的生产和消费，无需关注其具体的存储和计算细节。