A Prometheus/Loki remote write proxy that adds Cortex/Mimir/Loki tenant IDs to metrics and logs based on labels.
cortex-tenant is a proxy service that sits between Prometheus/Loki and Cortex/Mimir/Loki backends, enabling multi-tenant writes from a single data source. It solves the limitation where Prometheus cannot natively send different tenant IDs for different metric jobs, allowing a single Prometheus instance to write to multiple isolated tenants by extracting tenant IDs from metric or log stream labels.
DevOps engineers and SREs managing multi-tenant Cortex, Mimir, or Loki deployments who need to route metrics and logs from a single Prometheus or Loki instance to multiple isolated tenants. It is also for teams with centralized monitoring infrastructure requiring tenant isolation without running multiple data source instances.
Developers choose cortex-tenant because it provides a lightweight, stable bridge that solves a specific infrastructure problem without modifying upstream data sources or storage backends. Its unique selling point is the ability to extract tenant IDs from configurable labels and perform parallel per-tenant writes, adhering to the Unix philosophy of doing one thing well.
Prometheus remote write proxy that adds Cortex/Mimir tenant ID based on metric labels
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Groups timeseries or log streams by tenant and issues parallel HTTP requests to the backend, improving throughput for multi-tenant writes, as described in the logic overview.
Supports configurable tenant label extraction, default tenants, label removal, and various operational settings via YAML or environment variables, evidenced by the detailed config section.
Adheres to the Unix philosophy of doing one thing well, marked as stable in the README, and designed as a minimal bridge without bloat.
Handles both Prometheus remote write for Cortex/Mimir and Loki push APIs with separate configurable targets, making it versatile for metrics and logs in multi-tenant setups.
The author states no active work due to not working with Cortex/Mimir currently, which could slow bug fixes or feature updates, as noted in the Status section.
Prometheus metadata requests are sent only to the default tenant or dropped if none is defined, lacking per-tenant routing for metadata, as explained in the config comments.
Tenant identification relies solely on configurable labels from metrics or logs, which may not suit environments where tenant context is derived from other sources like HTTP headers.
Requires additional infrastructure to deploy and manage the proxy, adding complexity compared to native multi-tenancy solutions or integrated services.