Prometheus本身其实非常棒:它提供了出色的查询语言和统一的收集、发布指标的方法。不过,要让Prometheus具备高可用性和可扩展性却是一个不小的挑战。
我们需要以下这些特性:
而这就是Thanos的用武之地。
Thanos最基本的功能就是让你可以一次查询多个Prometheus实例,并且能够对来自多个实例的相同指标进行去重。这样你就可以运行多个相同的Prometheus副本,而无需担心重复指标。
Thanos边车是Thanos提供的一个组件,它与每个Prometheus容器一起运行,共同形成一个集群。你实际上查询的是Thanos Query组件,而不是Prometheus实例。下图有助于理解Prometheus与Thanos之间的关系。
光是这一点就已经很棒了,因为它可以让你轻松地实现高可用的Prometheus。除此之外,你还可以使用这些构建块做更多的事情。
下一个问题是如何将所有指标集中到一个地方。
我们运行了多个Kubernetes集群,每个集群都有自己的Prometheus实例。我们之前通常是通过使用特殊的Prometheus来抓取每个Prometheus实例的联合端点来聚合它们的指标。这样确实可行,但是太浪费资源了,因为我们复制了所有指标,而且这个特殊的Prometheus存在单点故障问题。
Thanos Query节点可以将另一个Query节点作为数据源,如果将集群中Thanos Query节点的gRPC端点公开,就可以将它们作为数据存储,并创建聚合它们的Thanos Query,见下图。
我们可以使用一个Thanos Query来获取所有集群的指标。在下面的屏幕截图中,我只用一个查询查询三个集群(红色、黑色、蓝色)中的Daemonset副本数量。
但是这个设置仍然存在问题,因为在每个集群中都有一个特殊的Thanos Query,我们通过它将获取指标视图,如果它宕机就会导致不可用。我们希望运行多个Thanos Query节点,每个集群中都有一个这样的节点,实现用户查询的负载均衡。通过使用我们的AWS多集群负载均衡工具Yggdrasil,可以在多个Kubernetes集群中分配流量。用户可以查询任意的集群,并接收所有的指标。
当我们把它们放在一起时看起来像这样:
请注意,每个Thanos Query层都是Thanos Query节点的副本集,这样做是为了增加弹性。
这为我们提供了一个令人难以置信的弹性Prometheus设置,跨多个集群,并具有多个副本,为我们提供了大量的冗余层。如果你想查看Prometheus指标,可以直接在一个地方查看,而无需操心应用程序所在的集群和命名空间等问题。
Prometheus的另一个常见问题是备份和保留所有指标。将数据保存在Prometheus实例上通常很昂贵,并且会影响性能。Thanos通过边车不断将数据备份到云存储(如S3),然后通过Store节点公开数据来解决这个问题。Store节点让你感觉好像在Thanos集群中有另一个Prometheus实例,但所有数据都来自S3存储桶。
如果集群发生故障,Store节点也会为我们提供一些很好的弹性。因为如果Prometheus实例消失,就无法查询到最新的数据,但我仍然可以通过查询另一个集群中的Store节点来访问数据,因为这些节点可以访问S3中的历史数据。
一直以来,我们很想做的一件事情是可以按照团队或命名空间来拆分Prometheus集群,这样,每个Prometheus实例就不会太大,并且具备了冗余,避免有团队产生大量的指标搞垮Prometheus。但这样做会非常费力,因为为每个团队或命名空间设置一个单独的端点会带来很多开销,但是有了Thanos,我们就可以将基于团队的Prometheus添加到Thanos集群中,并且仍然可以使用相同的单一指标来源。因此,我们希望切换到使用很多小型的Prometheis,并使用Prometheus Operator来创建它们。
总的来说,Thanos给了我们:
Thanos确实将我们的指标设置提升到了一个新的水平,简化了用户查询指标的方式,并为我们提供了一定的弹性。现在,从新的Kubernetes集群添加指标变得非常容易。不过,有一点需要注意的是,Thanos仍然是一个相对较新的产品,所以它可能还是会存在一些奇怪的bug,幸好它的背后有一个非常活跃的团队和社区在不断地改进它。如果你想加入他们,可以看看他们的Github项目或Slack频道。
英文原文:https://medium.com/uswitch-labs/making-prometheus-more-awesome-with-thanos-fbec8c6c28ad