使用 Thanos 和 Prometheus 打造一个高可用的 Kubernetes 监控系统

集群容量概览

直到今年 1 月，我一直在使用一款企业级监控解决方案来监控 Kubernetes 集群，这款监控方案还用于 APM。它用起来很自然，与 Kubernetes 的集成非常容易，只需要进行一些细微的调整，并且可以集成 APM 和基础设施指标。

尽管这款监控方案可以很容易地收集和存储数据，但使用指标创建警报却有很大的查询限制。经常我们收到的告警和仪表盘上显示的内容会不一样。更不用说我们有 6 个集群，收集和存储的指标数量非常多，这在很大程度上增加了我们的经济成本。

经过一番考虑，我们认识到继续使用这款监控方案弊大于利。是时候替换我们的监控方案了！但是，该使用什么产品或者工具呢？Grafana 是可视化工具的最佳选项，但我们的“后端”需要具备弹性伸缩和高可用能力，该使用什么工具呢？

纯粹使用 OpenTSDB 的话，安装需要太多的工作和精力；单机 Prometheus 不提供复制能力，还需要为其配备多个数据库；TimeScaleDB 看起来不错，但我不太会使用 PostgreSQL。

在对以上这些方案进行了一些实验后，我查看了 CNCF 网站，最后找到了 Thanos！它满足我们所有的需求：可长期保留数据、可复制、高可用、适合微服务、对使用相同数据库的所有集群有一个 global view！

架构

我们的集群上没有可用的持久化存储（所有服务都保持无状态），所以默认的 Prometheus + Thanos sidecar 方法不可用，metric 存储必须置于集群之外。此外，集群之间相互隔离，将 Thanos 组件绑定到一组特定的集群是不可能的，必须从“外部”监控集群。

综上所述，考虑到高可用性以及 Thanos 在虚拟机上运行的可能性，我们最终的架构是这样的：

如图所示，我们是多数据中心的架构。其中每个中心都有一组 Grafana + Query 服务器，一组存储服务器和三个 Receive 服务器（集群数量的一半）。

Grafana 使用的数据库还有一个 AWS RDS。这个数据库不必很庞大（降低成本），我们团队也不需要管理 MySQL。

在 Thanos 提供的所有组件中，我们实现了其中的 4 个：

• Receive：负责 TSDB，还管理所有运行 receive 的服务器和 TSBD 块上传到 S3 之间的复制。
• Query：负责查询 receive 数据库。
• Store：读取 S3 以获取不再存储在 receive 中的长期 metrics。
• Compactor：管理存储在 S3 中的 TSDB 块的数据下采样和压缩。

Data Ingestion

所有集群的 data ingestion 都由集群内运行的专用 Prometheus Pod 管理。它从 control plate（API 服务器、控制器和调度程序）、etcd 集群以及集群内的 Pod 收集指标，这些集群内具有与基础设施和 Kubernetes 本身相关的指标（Kube-proxy、Kubelet、Node Exporter、State Metrics 、Metrics Server 和其他具有 scraping annotation 的 Pod）。

Prometheus Pod 然后将信息发送到使用远程存储配置管理 TSDB 的 receive 服务器之一。

data ingestion

所有数据都发送到单个服务器，然后复制到其他服务器。Prometheus 使用的 DNS 地址是一个 DNS GSLB，它探测每个 receive 服务器并平衡健康的服务器之间的 DNS 解析，在所有服务器之间分担负载，因为 DNS 解析只为每个 DNS 查询提供一个 IP。

需要强调一下，数据必须发送到单个 receive 实例并让它管理复制，发送相同的 metric 会导致复制失败和行为异常。

在这个层面上，metrics 也会上传到 S3 存储桶进行长期留存。Receive 每 2 小时（当每个 TSDB 块关闭时）上传一次 block，这些 metric 可用于使用 Store 组件进行查询。

还可以设置本地数据的保留时间。在这种情况下，所有本地数据都会保留 30 天以供日常使用和故障排除，这样可以加快查询速度。

超过 30 天的数据仅在 S3 上可用，最长可保留 1 年，用于长期评估和比较。

数据查询

数据被收集并存储在 receiver 中以供查询。这部分也设置为多数据中心可用。

每台服务器都运行 Grafana 和 Query，如果其中一台（或两台）出现故障，我们可以更轻松地从负载均衡器中识别并删除。在 Grafana 中，数据源配置为 localhost，因此它始终使用本地 Query 来获取数据。

对于查询配置，它必须知道所有存储了 metrics 的服务器（Receiver 和 Store）。query 组件知道哪个服务器在线并且能够从它们收集 metrics。

数据查询

它还管理重复数据删除，因为它查询所有服务器并配置了 replication，所有 metrics 都有多个副本。可以使用分配给 metrics 的标签和查询参数 (​​--query.replica-label=QUERY.REPLICA-LABEL​​) 来完成。通过这些配置，query 组件知道从 Receiver 和 Store 收集的 metrics 是否重复并仅使用一个数据点。

长期数据

如前所述，数据在本地最多保留 30 天，其他所有内容都存储在 S3 上。这样可以减少 Receiver 上所需的空间量并降低成本，因为块存储比对象存储更贵。更何况查询超过 30 天的数据不是很常见，主要用于资源使用历史和预测。

远程数据查询

该 Store 还保留存储在 S3 存储桶上的每个 TSDB 块的索引的本地副本，因此如果需要查询超过 30 天的数据，它知道要下载和使用哪些块来提供数据。

数据情况

考虑到所有集群，该监控方案：

• 监控了 6 个 Kubernetes 集群；
• 收集了 670 个服务的 metrics；
• 使用 Node Exporter 监控了 246 个服务器；
• 每分钟收集约 27w 个指标；
• 每天 ingest 约 7.3 GB 的数据，或每月 ingest 约 226.3 GB 的数据；
• 为 Kubernetes 组件创建了 40 个专用仪表盘；
• 在 Grafana 上创建了 116 个警报。

对于每月费用，由于大部分组件在本地运行，成本降低了 90.61%，从每月 38,421.25 美元降至 3,608.99 美元，其中包括 AWS 服务成本。

总结

配置和设置上述架构大约需要一个月左右的时间，包括测试其他一些解决方案、验证架构、实现、在集群上开启收集以及创建所有仪表盘。

在第一周，好处是显而易见的。监控集群变得更加容易，仪表盘可以快速构建和定制，收集 metrics 几乎是即插即用的，大多数应用程序以 Prometheus 格式导出 metrics，并根据 annotations 自动收集。

此外，通过集成 Grafana 的 LDAP 可以达到更精细的团队权限控制。开发人员和 SRE 可以访问大量仪表盘，其中包含有关其命名空间、ingress 等的相关 metrics。