最牛逼的集群监控系统！它一直位列第一《Prometheus》

115资源网 2022年4月24日实用教程, 技术分享浏览：23 0

Prometheus 是 Kubernetes 中默许的监控计划，它专注于告警和搜集存储最近的监控目标。但在一定的集群规模下，Prometheus 也暴露出一些问题。例如：

怎么以经济牢靠的办法存储 PB 等级的历史数据，而且不献身查询时间？

怎么经过单一的查询接口访问到不同 Prometheus 服务器上的一切目标数据？

能否以某种办法兼并采集到的重复数据？

针对以上的这些问题，Thanos 供给了高可用的的解决计划，而且它有着不受约束的数据存储才能。

Kubernetes普罗米修斯技能栈

在为咱们的客户布置Kubernetes基础设施时，在每个集群上布置监控技能栈是规范做法。这个堆栈一般由几个组件组成：

Prometheus：搜集衡量规范

告警管理器：依据目标查询向各种供给者发送警报

Grafana：可视化奢华仪表板

简化架构如下：

注意事项

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

多个Grafana

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

存储目标数据是昂贵的

Prometheus将目标数据存储在磁盘上，你必须在存储空间和目标保存时间之间做出挑选。假如你想长时间存储数据并在云供给商上运转，那么假如存储TB的数据，块存储的本钱或许会很高。同样，在出产环境中，Prometheus经常运用仿制或分片或两者一同运转，这或许会使存储需求添加两倍甚至四倍。

解决计划

多个Grafana数据源

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

Prometheus联邦

Prometheus联邦答应从Prometheus中抓取Prometheus，当你不抓取许多目标数据时，这个解决计划能够很好地作业。在规模上，假如你一切的Prometheus目标的抓取持续时间都比抓取距离长，或许会遇到一些严重的问题。

Prometheus长途写

虽然长途写入是一种解决计划（也由Thanos receiver完成），但咱们将不在本文中评论“推送目标”部分。主张在不信赖多个集群或租户的情况下（例如在将Prometheus构建为服务供给时），将目标作为最终的手法。无论怎么，这或许是今后文章的主题，但咱们将在这儿集中评论抓取。

Thanos，它来了

Thanos是一个“开源的，高可用的Prometheus体系，具有长时间存储才能”。许多知名公司都在运用Thanos，也是CNCF孵化项目的一部分。

Thanos的一个主要特点便是答应“无限”存储空间。经过运用目标存储（比如S3），几乎每个云供给商都供给目标存储。假如在条件环境下运转，目标存储能够经过rook或minio这样的解决计划供给。

它是怎么作业的？

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

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

Thanos Sidecar

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集群中，依据用例的不同，有些办法比其他办法更好，在这儿咱们不能给出详细的介绍。

咱们的比如是在AWS上运转，运用tEKS布置了2个集群，咱们的all in one解决计划将出产安排妥当的EKS集群布置在AWS上：

一个调查者集群

一个被调查集群

咱们的布置运用了官方的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 -n monitoring get pods
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          120m
kube-prometheus-stack-grafana-c8768466b-rd8wm               2/2     Running   0          120m
kube-prometheus-stack-kube-state-metrics-5cf575d8f8-x59rd   1/1     Running   0          120m
kube-prometheus-stack-operator-6856b9bb58-hdrb2             1/1     Running   0          119m
kube-prometheus-stack-prometheus-node-exporter-8hvmv        1/1     Running   0          117m
kube-prometheus-stack-prometheus-node-exporter-cwlfd        1/1     Running   0          120m
kube-prometheus-stack-prometheus-node-exporter-rsss5        1/1     Running   0          120m
kube-prometheus-stack-prometheus-node-exporter-rzgr9        1/1     Running   0          120m
prometheus-kube-prometheus-stack-prometheus-0               3/3     Running   1          120m
thanos-compactor-74784bd59d-vmvps                           1/1     Running   0          119m
thanos-query-7c74db546c-d7bp8                               1/1     Running   0          12m
thanos-query-7c74db546c-ndnx2                               1/1     Running   0          12m
thanos-query-frontend-5cbcb65b57-5sx8z                      1/1     Running   0          119m
thanos-query-frontend-5cbcb65b57-qjhxg                      1/1     Running   0          119m
thanos-storegateway-0                                       1/1     Running   0          119m
thanos-storegateway-1                                       1/1     Running   0          118m
thanos-storegateway-observee-storegateway-0                 1/1     Running   0          12m
thanos-storegateway-observee-storegateway-1                 1/1     Running   0          11m
thanos-tls-querier-observee-query-dfb9f79f9-4str8           1/1     Running   0          29m
thanos-tls-querier-observee-query-dfb9f79f9-xsq24           1/1     Running   0          29m

kubectl -n monitoring get ingress
NAME                            CLASS    HOSTS                                            ADDRESS                                                                         PORTS     AGE
kube-prometheus-stack-grafana      grafana.thanos.teks-tg.clusterfrak-dynamics.io   k8s-ingressn-ingressn-afa0a48374-f507283b6cd101c5.elb.eu-west-1.amazonaws.com   80, 443   123m

被调查者：

kubectl -n monitoring get pods
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          39m
kube-prometheus-stack-kube-state-metrics-5cf575d8f8-ct292   1/1     Running   0          39m
kube-prometheus-stack-operator-6856b9bb58-4cngc             1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-bs4wp        1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-c57ss        1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-cp5ch        1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-tnqvq        1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-z2p49        1/1     Running   0          39m
kube-prometheus-stack-prometheus-node-exporter-zzqp7        1/1     Running   0          39m
prometheus-kube-prometheus-stack-prometheus-0               3/3     Running   1          39m
thanos-compactor-7576dcbcfc-6pd4v                           1/1     Running   0          38m

kubectl -n monitoring get ingress
NAME                                   CLASS   HOSTS                                                   ADDRESS                                                                         PORTS     AGE
kube-prometheus-stack-thanos-gateway   nginx   thanos-sidecar.thanos.teks-tg.clusterfrak-dynamics.io   k8s-ingressn-ingressn-95903f6102-d2ce9013ac068b9e.elb.eu-west-3.amazonaws.com   80, 443   40m

咱们的TLS查询器应该能够查询被观测集群的衡量规范。让咱们来看看它们的行为：

k -n monitoring logs -f thanos-tls-querier-observee-query-687dd88ff5-nzpdh

level=info ts=2021-02-23T15:37:35.692346206Z caller=storeset.go:387 component=storeset msg=\"adding new storeAPI to query storeset\" address=thanos-sidecar.thanos.teks-tg.clusterfrak-dynamics.io:443 extLset=\"{cluster=\\\"pio-thanos-observee\\\", prometheus=\\\"monitoring/kube-prometheus-stack-prometheus\\\", prometheus_replica=\\\"prometheus-kube-prometheus-stack-prometheus-0\\\"}\"

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

kubectl -n monitoring port-forward thanos-tls-querier-observee-query-687dd88ff5-nzpdh 10902

太棒了，但是我只有一个存储，还记得咱们说过查询器能够堆叠在一同吗？在咱们的调查者集群中，咱们有规范的http查询器，它能够查询架构图中的其他组件。kubectl -n monitoring port-forward thanos-query-7c74db546c-d7bp8 10902

这儿咱们能够看到一切的存储现已被添加到咱们的中心查询器：

调查者把本地Thanos聚集

咱们的存储网关（一个用于长途观测者集群，一个用于本地观测者集群）

本地TLS查询器，它能够查询被调查的sidecar

在Grafana可视化

最终，咱们能够前往Grafana，看看默许的Kubernetes仪表板是怎么与多集群兼容的。

总结

Thanos是一个非常复杂的体系，有许多移动部件，咱们没有深化研究详细的自定义装备，因为它会花费太多的时间。

咱们在tEKS存储库中供给了一个适当完好的AWS完成，它笼统了许多复杂性（主要是mTLS部分），并答应进行许多定制。你也能够运用terraform-kubernetes-addons模块作为独立的组件。咱们计划在未来支撑其他云供给商。不要犹豫，经过Github上的任何一个项目的问题联络咱们。

依据你的基础设施和需求，有许多或许合适你的Thanos完成。

假如你想深化研究Thanos，能够检查他们的官方kube-thanos存储库，以及他们关于跨集群通讯的主张。

Kubernetes普罗米修斯技能栈
Thanos，它来了
多集群架构
再深化一点
在Grafana可视化
总结
目录