Ensuring that systems run reliably is a critical function of a site reliability engineer. A big part of that is to collect metrics, create alerts and graph data. It’s of the utmost importance to gather system metrics, from several locations and services, and correlate them to understand system functionality as well as to support troubleshooting.

Prometheus, a Cloud Native Computing Foundation (CNCF) project, has become one of the most popular open source solutions for application and system monitoring. A single instance can handle millions of time series, but when systems grow, Prometheus needs to be able to scale and handle the increased load. Because vertical scaling will eventually hit a limit, you need another solution.

This article will guide you through transforming a simple Prometheus setup into a Thanos deployment. That setup will enable you to perform reliable queries to multiple Prometheus instances from a single endpoint, seamlessly handling a highly available Prometheus setup.

Implement Global View and High Availability 

Thanos provides a set of components that can deliver a highly available metric system, with virtually unlimited storage capacity. It can be added on top of existing Prometheus deployments and provide capabilities like global query view, data backup and historical data access. Moreover, these features run independently of each other, which allows you to onboard Thanos features only when needed.

Initial Cluster Setup

You’ll be deploying Prometheus in a Kubernetes cluster, where you’ll simulate the desired scenario. The kind tool is a good solution to launch a Kubernetes cluster locally. You’ll use the following configuration.

With this configuration, you’re ready to launch the cluster.

With the cluster up and running, you’ll check the installation to be sure you’re ready to launch Prometheus. You’ll need kubectl to interact with the Kubernetes cluster.

With this configuration, you’re ready to launch the cluster.

With the cluster up and running, you’ll check the installation to be sure you’re ready to launch Prometheus. You’ll need kubectl to interact with the Kubernetes cluster.

Initial Prometheus Setup

Your goal is to deploy Thanos on top of an existing Prometheus installation and extend its functionality. With that in mind, you’ll start by launching three Prometheus servers. There are several reasons to have multiple Prometheus instances like sharding, high availability or query aggregation from multiple locations.

For this scenario, let’s imagine the following setup: you have one Prometheus server in a cluster in the United States and two replicas of Prometheus server in Europe that scrape the same targets.

To deploy Prometheus, you’ll use the kube-prometheus-stack chart, and you’ll need Helm. After installing Helm, you’ll need to add the kube-prometheus-stack repository.

Because in practice you only have one Kubernetes cluster, you’ll simulate multiple regions by deploying Prometheus in different namespaces. You’ll create namespaces for europe and another for united-states.

Now that you have your regions, you’re ready to deploy Prometheus.

Using the configurations above, you’ll deploy the Prometheus instances in each region.

You can now ensure your Prometheus is working as expected.

You’re now able to query any metrics on each individual instance, but unable to perform multicluster queries.

Deploy Thanos Sidecars

kube-prometheus-stack supports deploying Thanos as a sidecar, meaning it will be deployed alongside Prometheus itself. Thanos sidecar exposes Prometheus through the StoreAPI, a generic gRPC API that allows Thanos components to fetch metrics from various systems.

With the updated configuration, you’re ready to upgrade Prometheus.

You can check that the Prometheus pods have an extra container running alongside them.

Deploy Thanos Querier to Achieve Global View

Querier implements the Prometheus HTTP v1 API to query data in a Thanos cluster via PromQL. It will allow you to fetch metrics from a single endpoint. It starts by gathering the data needed to evaluate a query from underlying StoreAPIs, evaluates the query and then returns the result.

You leveraged kube-prometheus-stack to deploy Thanos sidecar. Unfortunately, that chart does not support other Thanos components. For that, you’ll take advantage of the Banzai Cloud Helm Charts repository.  As before, you’ll start by adding the repository, the same way you did before.

To simulate a central monitoring solution, you’ll create a monitoring namespace.

The following configuration configures Thanos Querier and points it to the Prometheus instances.

With the above configuration, you’re ready to deploy Querier.

Using port-forward, you can connect to your cluster. You can ensure that you can perform multicluster queries. When you deployed Prometheus, you set replicaExternalLabelName: “replica” and prometheusExternalLabelName: “cluster”. The deduplication functionality will take advantage of those. By enabling it, you can ensure metrics from the europe cluster are deduplicated. That’s because Thanos assumes them to be from the same high-availability group. This happens because they have the same labels, except for the replica label.

Deploy Thanos Query Frontend to improve readability

The last piece of the puzzle will be to deploy Query Frontend, a service that can be put in front of queriers to improve readability. It is based on the Cortex Query Frontend component and supports features like splitting, retries, caching and slow query log.

Updating the previous configuration to deploy Query Frontend, you now can update your setup.

Using port-forward again, you’ll be able to access Query Frontend.

Query Frontend is the entry point to send queries to multiple Prometheus instances. Services that perform these types of queries, such as Grafana, should make them through Query Frontend.

Conclusion

In this article, you’ve gone through the steps required to go from a simple metrics-gathering solution to a global, highly available setup. In this setup, you leveraged Prometheus and Thanos in a Kubernetes cluster.

You started by deploying Prometheus instances separately, simulating a multiregion setup, and then proceeded to add functionality incrementally. You started by injecting Thanos as a sidecar, implementing the Store API on top of Prometheus and paving the way to deploy Querier. Querier gathers data from the underlying Store APIs, evaluates queries and returns results. Lastly, you deployed Query Fronted, a component aimed at improving readability that supports features like splitting, retries, caching and slow query log.

This setup allows you to run multi-replica Prometheus servers, in a highly available setup, and paves the way for more complex scenarios.

Plug: Use K8s with Squadcast for Faster Resolution

Squadcast is an incident management tool that’s purpose-built for SRE. Get rid of unwanted alerts, receive relevant notifications and integrate with popular ChatOps tools. Work in collaboration using virtual incident war rooms and use automation to eliminate toil.

Ricardo is a site reliability engineer at Anova. He is a technical author and speaker who loves writing and speaking about SRE, software engineering, DevOps and cloud native.

Read more from Ricardo Castro