Prometheus Agent Prometheus多集群监控 prometheus监控多个k8s容器

转载

mob64ca1401464d 2024-06-11 08:45:20

文章标签 prometheus kubernetes 数据库数据服务器 文章分类 云原生云计算

概述

对于弹性伸缩和高可用的系统来说，一般有大量的指标数据需要收集和存储，如何为这样的系统打造一个监控方案呢？本文介绍了如何使用 Thanos+Prometheus+Grafana 构建监控系统。

Prometheus Agent Prometheus多集群监控 prometheus监控多个k8s容器_prometheus

集群容量概览

用户故事

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

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

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

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

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

架构

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

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

Prometheus Agent Prometheus多集群监控 prometheus监控多个k8s容器_kubernetes_02

如图所示，我们是多数据中心的架构。其中每个中心都有一组 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 都由集群内运行的专用 Prometheus Pod 管理。它从 control plate（API 服务器、控制器和调度程序）、etcd 集群以及集群内的 Pod 收集指标，这些集群内具有与基础设施和 Kubernetes 本身相关的指标（Kube-proxy、Kubelet、Node Exporter、State Metrics 、Metrics Server 和其他具有 scraping annotation 的 Pod）。

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

Prometheus Agent Prometheus多集群监控 prometheus监控多个k8s容器_kubernetes_03

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。

Prometheus Agent Prometheus多集群监控 prometheus监控多个k8s容器_数据_04

数据查询

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