提升 Prometheus 的可用性：一文读懂Thanos 多集群监控 _云计算

介绍

在本文中，我们将看到Prometheus监控技术栈的局限性，以及为什么移动到基于Thanos的技术栈可以提高指标留存率并降低总体基础设施成本。

用于此演示的内容可以在下面链接中获取，并提交到他们各自的许可证。

https://github.com/particuleio/teks/tree/main/terragrunt/live/thanos
https://github.com/particuleio/terraform-kubernetes-addons/tree/main/modules/aws

Kubernetes技术栈

在为我们的客户部署Kubernetes基础设施时，在每个集群上部署监控技术栈是标准做法。这个堆栈通常由几个组件组成：

Prometheus：收集度量标准
告警管理器：根据指标查询向各种提供者发送警报
Grafana：可视化豪华仪表板

简化架构如下：

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

注意事项

这种架构有一些注意事项，当你想从其中获取指标的集群数量增加时，它的伸缩性以及可扩展性不太好。

多个Grafana

在这种设置中，每个集群都有自己的Grafana和自己的一组仪表板，维护起来很麻烦。

存储指标数据是昂贵的

Prometheus将指标数据存储在磁盘上，你必须在存储空间和指标保留时间之间做出选择。如果你想长时间存储数据并在云提供商上运行，那么如果存储TB的数据，块存储的成本可能会很高。同样，在生产环境中，Prometheus经常使用复制或分片或两者同时运行，这可能会使存储需求增加两倍甚至四倍。

解决方案

多个Grafana数据源

可以在外部网络上公开Prometheus的端点，并将它们作为数据源添加到单个Grafana中。你只需要在Prometheus外部端点上使用TLS或TLS和基本认证来实现安全性。此解决方案的缺点是不能基于不同的数据源进行计算。

Prometheus联邦

Prometheus联邦允许从Prometheus中抓取Prometheus，当你不抓取很多指标数据时，这个解决方案可以很好地工作。在规模上，如果你所有的Prometheus目标的抓取持续时间都比抓取间隔长，可能会遇到一些严重的问题。

Prometheus远程写

虽然远程写入是一种解决方案（也由Thanos receiver实现），但我们将不在本文中讨论“推送指标”部分。你可以在这里[1]阅读关于推送指标的利弊。建议在不信任多个集群或租户的情况下（例如在将Prometheus构建为服务提供时），将指标作为最后的手段。无论如何，这可能是以后文章的主题，但我们将在这里集中讨论抓取。

Thanos，它来了

Thanos是一个“开源的，高可用的Prometheus系统，具有长期存储能力”。很多知名公司都在使用Thanos，也是CNCF孵化项目的一部分。

Thanos的一个主要特点就是允许“无限”存储空间。通过使用对象存储（比如S3），几乎每个云提供商都提供对象存储。如果在前提环境下运行，对象存储可以通过rook或minio这样的解决方案提供。

它是如何工作的？

Thanos和Prometheus并肩作战，从Prometheus开始升级到Thanos是很常见的。

Thanos被分成几个组件，每个组件都有一个目标（每个服务都应该这样:)），组件之间通过gRPC进行通信。

Thanos Sidecar

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

Thanos和Prometheus一起运行（有一个边车），每2小时向一个对象存储库输出Prometheus指标。这使得Prometheus几乎是无状态的。Prometheus仍然在内存中保存着2个小时的度量值，所以在发生宕机的情况下，你可能仍然会丢失2个小时的度量值（这个问题应该由你的Prometheus设置来处理，使用HA/分片，而不是Thanos）。

Thanos sidecar与Prometheus运营者和Kube Prometheus栈一起，可以轻松部署。这个组件充当Thanos查询的存储。

Thanos存储

Thanos存储充当一个网关，将查询转换为远程对象存储。它还可以在本地存储上缓存一些信息。基本上，这个组件允许你查询对象存储以获取指标。这个组件充当Thanos查询的存储。

Thanos Compactor

Thanos Compactor是一个单例（它是不可扩展的），它负责压缩和降低存储在对象存储中的指标。下采样是随着时间的推移对指标粒度的宽松。例如，你可能想将你的指标保持2年或3年，但你不需要像昨天的指标那么多数据点。这就是压缩器的作用，它可以在对象存储上节省字节，从而节省成本。

Thanos Query

Thanos查询是Thanos的主要组件，它是向其发送PromQL查询的中心点。Thanos查询暴露了一个与Prometheus兼容的端点。然后它将查询分派给所有的“stores”。记住，Store可能是任何其他提供指标的Thanos组件。Thanos查询可以发送查询到另一个Thanos查询（他们可以堆叠）。

Thanos Store
Thanos Sidecar
Thanos Query

还负责对来自不同Store或Prometheus的相同指标进行重复数据删除。例如，如果你有一个度量值在Prometheus中，同时也在对象存储中，Thanos Query可以对该指标值进行重复数据删除。在Prometheus HA设置的情况下，重复数据删除也基于Prometheus副本和分片。

Thanos Query Frontend

正如它的名字所暗示的，Thanos查询前端是Thanos查询的前端，它的目标是将大型查询拆分为多个较小的查询，并缓存查询结果（在内存或memcached中）。

还有其他组件，比如在远程写的情况下接收Thanos，但这仍然不是本文的主题。

多集群架构

有多种方法可以将这些组件部署到多个Kubernetes集群中，根据用例的不同，有些方法比其他方法更好，在这里我们不能给出详细的介绍。

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

我们的例子是在AWS上运行，使用tEKS[2]部署了2个集群，我们的all in one解决方案将生产就绪的EKS集群部署在AWS上：

一个观察者集群[3]
一个被观察集群[4]

我们的部署使用了官方的kube-prometheus-stack和bitnami thanos图表。

一切都是在我们的terraform-kubernetes-addons存储库中策划的。

Thanos demo文件夹中的目录结构如下：

.
├──env_tags.yaml
├──eu-west-1
│├──clusters
││└──observer
││├──eks
│││├──kubeconfig
│││└──terragrunt.hcl
││├──eks-addons
│││└──terragrunt.hcl
││└──vpc
││└──terragrunt.hcl
│└──region_values.yaml
└──eu-west-3
├──clusters
│└──observee
│├──cluster_values.yaml
│├──eks
││├──kubeconfig
││└──terragrunt.hcl
│├──eks-addons
││└──terragrunt.hcl
│└──vpc
│└──terragrunt.hcl
└──region_values.yaml

这允许DRY（Don 't Repeat Yourself）基础设施，并可以轻松地扩展AWS帐户、区域和集群的数量。

观察者集群

观察者集群是我们的主集群，我们将从它查询其他集群：

Prometheus正在运行：

Grafana启用
Thanos边车上传到特定的桶

kube-prometheus-stack={
enabled= true
allowed_cidrs=dependency.vpc.outputs.private_subnets_cidr_blocks
thanos_sidecar_enabled= true
thanos_bucket_force_destroy= true
extra_values=<<-EXTRA_VALUES
grafana:
deploymentStrategy:
type:Recreate
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class:nginx
cert-manager.io/cluster-issuer: "letsencrypt"
hosts:
-grafana. ${local.default_domain_suffix}
tls:
-secretName:grafana. ${local.default_domain_suffix}
hosts:
-grafana. ${local.default_domain_suffix}
persistence:
enabled: true
storageClassName:ebs-sc
accessModes:
-ReadWriteOnce
size:1Gi
prometheus:
prometheusSpec:
replicas:1
retention:2d
retentionSize: "10GB"
ruleSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
podMonitorSelectorNilUsesHelmValues: false
storageSpec:
volumeClaimTemplate:
spec:
storageClassName:ebs-sc
accessModes:[ "ReadWriteOnce"]
resources:
requests:
storage:10Gi
EXTRA_VALUES

为观察者集群生成一个CA证书：

这个CA将被进入sidecar的被观察集群所信任
为Thanos querier组件生成TLS证书，这些组件将查询被观察集群

Thanos组件部署：

Thanos组件全部部署完成
查询前端，作为Grafana的数据源端点
存储网关用于查询观察者桶
Query将对存储网关和其他查询器执行查询

部署的额外Thanos组件：

配置了TLS的Thanos查询器对每个被观察集群进行查询

thanos-tls-querier={


"observee"={

enabled=
true

default_global_requests=
true

default_global_limits=
false

stores=[


"thanos-sidecar.
${local.default_domain_suffix}:443"

]

}

}



thanos-storegateway={


"observee"={

enabled=
true

default_global_requests=
true

default_global_limits=
false

bucket=
"thanos-store-pio-thanos-observee"

region=
"eu-west-3"

}

被观测集群

被观测集群是Kubernetes集群，具有最小的Prometheus/Thanos安装，将被观测集群查询。

Prometheus operator正在运行：

Thanos这边就是上传给观察者特定的桶
Thanos边车与TLS客户端认证的入口对象一起发布，并信任观察者集群CA

kube-prometheus-stack={
enabled= true
allowed_cidrs=dependency.vpc.outputs.private_subnets_cidr_blocks
thanos_sidecar_enabled= true
thanos_bucket_force_destroy= true
extra_values=<<-EXTRA_VALUES
grafana:
enabled: false
prometheus:
thanosIngress:
enabled: true
ingressClassName:nginx
annotations:
cert-manager.io/cluster-issuer: "letsencrypt"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "monitoring/thanos-ca"
hosts:
-thanos-sidecar. ${local.default_domain_suffix}
paths:
-/
tls:
-secretName:thanos-sidecar. ${local.default_domain_suffix}
hosts:
-thanos-sidecar. ${local.default_domain_suffix}
prometheusSpec:
replicas:1
retention:2d
retentionSize: "6GB"
ruleSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
podMonitorSelectorNilUsesHelmValues: false
storageSpec:
volumeClaimTemplate:
spec:
storageClassName:ebs-sc
accessModes:[ "ReadWriteOnce"]
resources:
requests:
storage:10Gi
EXTRA_VALUES

Thanos组件部署：

Thanos压缩器来管理这个特定集群的下采样

thanos={

enabled=
true

bucket_force_destroy=
true

trusted_ca_content=dependency.thanos-ca.outputs.thanos_ca

extra_values=<<-EXTRA_VALUES

compactor:

retentionResolution5m:90d

query:

enabled:
false

queryFrontend:

enabled:
false

storegateway:

enabled:
false

EXTRA_VALUES

}

再深入一点

让我们检查一下集群上正在运行什么。关于观察员，我们有：

kubectl-nmonitoringgetpods

NAMEREADYSTATUSRESTARTSAGE

alertmanager-kube-prometheus-stack-alertmanager-02/2Running0120m

kube-prometheus-stack-grafana-c8768466b-rd8wm2/2Running0120m

kube-prometheus-stack-kube-state-metrics-5cf575d8f8-x59rd1/1Running0120m

kube-prometheus-stack-operator-6856b9bb58-hdrb21/1Running0119m

kube-prometheus-stack-prometheus-node-exporter-8hvmv1/1Running0117m

kube-prometheus-stack-prometheus-node-exporter-cwlfd1/1Running0120m

kube-prometheus-stack-prometheus-node-exporter-rsss51/1Running0120m

kube-prometheus-stack-prometheus-node-exporter-rzgr91/1Running0120m

prometheus-kube-prometheus-stack-prometheus-03/3Running1120m

thanos-compactor-74784bd59d-vmvps1/1Running0119m

thanos-query-7c74db546c-d7bp81/1Running012m

thanos-query-7c74db546c-ndnx21/1Running012m

thanos-query-frontend-5cbcb65b57-5sx8z1/1Running0119m

thanos-query-frontend-5cbcb65b57-qjhxg1/1Running0119m

thanos-storegateway-01/1Running0119m

thanos-storegateway-11/1Running0118m

thanos-storegateway-observee-storegateway-01/1Running012m

thanos-storegateway-observee-storegateway-11/1Running011m

thanos-tls-querier-observee-query-dfb9f79f9-4str81/1Running029m

thanos-tls-querier-observee-query-dfb9f79f9-xsq241/1Running029m



kubectl-nmonitoringgetingress

NAMECLASSHOSTSADDRESSPORTSAGE

kube-prometheus-stack-grafana<none>grafana.thanos.teks-tg.clusterfrak-dynamics.iok8s-ingressn-ingressn-afa0a48374-f507283b6cd101c5.elb.eu-west-1.amazonaws.com80,443123m

被观察者：

kubectl-nmonitoringgetpods
NAMEREADYSTATUSRESTARTSAGE
alertmanager-kube-prometheus-stack-alertmanager-02/2Running039m
kube-prometheus-stack-kube-state-metrics-5cf575d8f8-ct2921/1Running039m
kube-prometheus-stack-operator-6856b9bb58-4cngc1/1Running039m
kube-prometheus-stack-prometheus-node-exporter-bs4wp1/1Running039m
kube-prometheus-stack-prometheus-node-exporter-c57ss1/1Running039m
kube-prometheus-stack-prometheus-node-exporter-cp5ch1/1Running039m
kube-prometheus-stack-prometheus-node-exporter-tnqvq1/1Running039m
kube-prometheus-stack-prometheus-node-exporter-z2p491/1Running039m
kube-prometheus-stack-prometheus-node-exporter-zzqp71/1Running039m
prometheus-kube-prometheus-stack-prometheus-03/3Running139m
thanos-compactor-7576dcbcfc-6pd4v1/1Running038m

kubectl-nmonitoringgetingress
NAMECLASSHOSTSADDRESSPORTSAGE
kube-prometheus-stack-thanos-gatewaynginxthanos-sidecar.thanos.teks-tg.clusterfrak-dynamics.iok8s-ingressn-ingressn-95903f6102-d2ce9013ac068b9e.elb.eu-west-3.amazonaws.com80,44340m

我们的TLS查询器应该能够查询被观测集群的度量标准。让我们来看看它们的行为：

k-nmonitoringlogs-fthanos-tls-querier-observee-query-687dd88ff5-nzpdh



level=infots=2021-02-23T15:37:35.692346206Z
caller=storeset.go:387component=storesetmsg=
"addingnewstoreAPItoquerystoreset"address=thanos-sidecar.thanos.teks-tg.clusterfrak-dynamics.io:443extLset=
"{cluster=\"pio-thanos-observee\",prometheus=\"monitoring/kube-prometheus-stack-prometheus\",prometheus_replica=\"prometheus-kube-prometheus-stack-prometheus-0\"}"

所以这个查询器pods可以查询我的其他集群，如果我们检查Web，我们可以看到存储：

kubectl-nmonitoringport-forwardthanos-tls-querier-observee-query-687dd88ff5-nzpdh10902

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

太棒了，但是我只有一个存储，还记得我们说过查询器可以堆叠在一起吗？在我们的观察者集群中，我们有标准的http查询器，它可以查询架构图中的其他组件。

kubectl-nmonitoringport-forwardthanos-query-7c74db546c-d7bp810902

这里我们可以看到所有的存储已经被添加到我们的中心查询器：

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

观察者把本地Thanos聚集
我们的存储网关（一个用于远程观测者集群，一个用于本地观测者集群）
本地TLS查询器，它可以查询被观察的sidecar

在Grafana可视化

最后，我们可以前往Grafana，看看默认的Kubernetes仪表板是如何与多集群兼容的。

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

总结

Thanos是一个非常复杂的系统，有很多移动部件，我们没有深入研究具体的自定义配置，因为它会花费太多的时间。

我们在tEKS存储库中提供了一个相当完整的AWS实现，它抽象了很多复杂性（主要是mTLS部分），并允许进行很多定制。你也可以使用terraform-kubernetes-addons模块作为独立的组件。我们计划在未来支持其他云提供商。不要犹豫，通过Github上的任何一个项目的问题联系我们。

根据你的基础设施和需求，有许多可能适合你的Thanos实现。

如果你想深入研究Thanos，可以查看他们的官方kube-thanos存储库，以及他们关于跨集群通信的建议[5]。

当然，我们很乐意帮助你设置你的云原生监控堆栈，欢迎联系我们contact@particule.io:)

你也可以每天通过CNCF/Kubernetes Slack频道联系我们。

提升 Prometheus 的可用性：一文读懂Thanos 多集群监控

介绍

Kubernetes技术栈

Thanos，它来了

多集群架构

再深入一点

在Grafana可视化

总结

延伸 · 阅读

云主机CPU和内存配比：优化资源分配的关键

云计算的自动化至关重要

云原生架构日志监控优秀实践

重磅！亚马逊云科技2023re:Invent黑科技剧透抢先看！

云拨测全面升级丨单次拨测低至 0.001 元

微软：将市值作为成功衡量指标非常危险云计算是我们的未来

救火分享：记一次 K8s 管理节点故障排查经历，太深入了

云计算 vs 边缘计算

云服务器是什么，云主机干什么用的？

2020最新好用的web服务器软件推荐

服务器操作系统有哪些?

web服务器配置（图文详解）

企业如何选择阿里云服务器配置?

五大免费主机管理系统优缺点对比及推荐

2019最新三款Windows下连接Linux的ssh软件下载推荐

服务器常用管理软件盘点

Nginx服务器究竟是怎么执行PHP项目