使用 Thanos 和 Prometheus 打造一个高可用的 Kubernetes 监控系统
对于弹性伸缩和高可用的系统来说,一般有大量的指标数据需要收集和存储,如何为这样的系统打造一个监控方案呢?本文介绍了如何使用 Thanos+Prometheus+Grafana 构建监控系统。
作者:Luiz Rojo
翻译:Sarah(K8sMeetup)
校对:FogDong(才云)
直到今年 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 服务器之一。
所有数据都发送到单个服务器,然后复制到其他服务器。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。
原文链接:https://luizrojo.medium.com/prometheus-but-bigger-b678d8d6b29d
本文转载自:「 K8sMeetup社区 」,原文:https://tinyurl.com/dref4r6x ,版权归原作者所有。