使用Thanos和Prometheus塑造一个高可用的Kubernetes监控系统
发布时间：2022-05-04 10:27:46 所属栏目：系统 来源：互联网
导读：直到今年 1 月，我一直在使用一款企业级监控解决方案来监控 Kubernetes 集群，这款监控方案还用于 APM。它用起来很自然，与 Kubernetes 的集成非常容易，只需要进行一些细微的调整，并且可以集成 APM 和基础设施指标。 尽管这款监控方案可以很容易地收集和存
|
直到今年 1 月，我一直在使用一款企业级监控解决方案来监控 Kubernetes 集群，这款监控方案还用于 APM。它用起来很自然，与 Kubernetes 的集成非常容易，只需要进行一些细微的调整，并且可以集成 APM 和基础设施指标。 尽管这款监控方案可以很容易地收集和存储数据，但使用指标创建警报却有很大的查询限制。经常我们收到的告警和仪表盘上显示的内容会不一样。更不用说我们有 6 个集群，收集和存储的指标数量非常多，这在很大程度上增加了我们的经济成本。 纯粹使用 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 年，用于长期评估和比较。 数据查询 它还管理重复数据删除，因为它查询所有服务器并配置了 replication，所有 metrics 都有多个副本。可以使用分配给 metrics 的标签和查询参数 (--query.replica-label=QUERY.REPLICA-LABEL) 来完成。通过这些配置，query 组件知道从 Receiver 和 Store 收集的 metrics 是否重复并仅使用一个数据点。 长期数据 如前所述，数据在本地最多保留 30 天，其他所有内容都存储在 S3 上。这样可以减少 Receiver 上所需的空间量并降低成本，因为块存储比对象存储更贵。更何况查询超过 30 天的数据不是很常见，主要用于资源使用历史和预测。 总结 配置和设置上述架构大约需要一个月左右的时间，包括测试其他一些解决方案、验证架构、实现、在集群上开启收集以及创建所有仪表盘。 在第一周，好处是显而易见的。监控集群变得更加容易，仪表盘可以快速构建和定制，收集 metrics 几乎是即插即用的，大多数应用程序以 Prometheus 格式导出 metrics，并根据 annotations 自动收集。 此外，通过集成 Grafana 的 LDAP 可以达到更精细的团队权限控制。开发人员和 SRE 可以访问大量仪表盘，其中包含有关其命名空间、ingress 等的相关 metrics。 （编辑：南通站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
