The sidecar component is meant to be deployed locally alongside Prometheus and connect to it via its remote-read API. Prometheus' remote-read API allows integration with other systems so that they can access samples as if they were locally available for them to query. This obviously introduces the network in the query path, which might cause bandwidth related issues. The sidecar takes advantage of this to make data available in Prometheus to other Thanos components. It exposes the store API as a gRPC endpoint (bound to port 10901 by default), which will then be used by the Thanos query component, effectively turning the sidecar into a datastore from the querier's point of view. Sidecar also exposes an HTTP endpoint on port 10902 with a handler for /metrics so that you can collect its internal metrics in Prometheus.

The Prometheus instance that the sidecar is attached to must set external_labels so that each instance is uniquely identified. This is essential for Thanos to filter out which store APIs to query and for deduplication to work.

In our test environment, we can find a Thanos sidecar running in each of the available shards. To quickly validate the configuration in use, we can run the following instruction in any shard instances:

vagrant@shard01:~$ systemctl cat thanos-sidecar
...
ExecStart=/usr/bin/thanos sidecar 
           --prometheus.url "http://localhost:9090"
...

The previous snippet indicates that the sidecar is connecting to the local Prometheus instance. Sidecar offers a lot more functionality, as we'll see in the next chapter, but for the purpose of implementing a global view, this configuration will suffice.