This component allows you to run Prometheus-compatible rules (recording/alerting) against remote query endpoints, such as Thanos querier or sidecar. It exposes a StoreAPI endpoint to make the results of rule evaluations available, which are stored in local blocks, and can also ship these TSDB blocks to object storage. It's tempting to imagine using this component as a solution for the centralized management of rules instead of spreading them across multiple Prometheus instances, but that's not its purpose and would be ill-advised. Throughout this book, we have stressed how critical rules are, especially for alerting. We also underlined the importance of running those rules locally in the Prometheus instance that has the required metrics. We've provided alternatives, such as a hierarchical or cross-service federation, for gathering metrics from different Prometheus instances. By using the Thanos ruler for alerting, you would be adding a number of points of failure to the critical path: other Thanos components, the network, and, in the worst case, object storage. Alerting needs to be predictable and reliable, so you can have a high level of confidence that it will work when you need it the most. Though Thanos ruler can have a legitimate set of use cases, it shouldn't be considered for most alerting needs. Nonetheless, it's important to acknowledge its existence.

We now have a complete overview of the Thanos ecosystem and how it's configured on the test environment. We invite you to experiment with all the components while evaluating their behavior: for example, stopping all the store APIs except the Thanos store or using the Thanos bucket to understand what data is available in the object storage bucket.