Grafana’s multi-organization feature doesn’t just let you segment data; it fundamentally changes how you think about shared infrastructure as a collection of isolated, self-contained monitoring domains.
Let’s see it in action. Imagine you have two distinct teams, "Alpha" and "Beta," each needing their own Grafana instance but sharing the same underlying Prometheus servers.
First, we need to enable the multi-organization feature in Grafana’s configuration. This is typically done in grafana.ini (or via environment variables).
[auth.local]
enabled = true
[auth.basic]
enabled = true
[users]
allow_sign_up = false
Then, we’ll configure the default organization. By default, Grafana starts with a single organization called "Main Org." We can rename this and set up our first tenant.
Now, let’s create a new organization for "Beta." From the Grafana UI, navigate to "Server Admin" -> "Orgs" -> "New Org." We’ll name it "Beta."
Once the "Beta" organization is created, we need to assign users to it. For a multi-tenant setup, you’ll want to manage users and their roles within each organization. You can add users to the "Beta" organization with specific roles (Viewer, Editor, Admin).
The real power comes when you start configuring data sources. Each organization can have its own set of data sources. This means the "Alpha" organization can point to its Prometheus instance, while the "Beta" organization can point to the same Prometheus instance but with a different job_name filter or even a different Prometheus server altogether, all managed independently.
For example, in "Main Org" (let’s say this is for "Alpha"), you’d add a Prometheus data source.
Data Source: Prometheus
- Name: Prometheus Alpha
- Type: Prometheus
- URL:
http://prometheus.internal:9090 - Access: Server (default)
Now, in the "Beta" organization, you’d add another Prometheus data source.
Data Source: Prometheus
- Name: Prometheus Beta
- Type: Prometheus
- URL:
http://prometheus.internal:9090 - Access: Server (default)
Crucially, you can then use queries within dashboards that are specific to each organization. For instance, a dashboard in "Main Org" might query up{job="my-app-alpha"} while a dashboard in "Beta" organization queries up{job="my-app-beta"}. Both queries hit the same Prometheus server but are filtered by the job label, effectively isolating the metrics being viewed.
The system also allows for granular control over user permissions per organization and even per dashboard. This means you can have a user who is an Admin in "Beta" but only a Viewer in "Main Org."
When setting up data sources for different tenants, you’re not just configuring a connection; you’re defining an access boundary for Prometheus queries. By using different data source names or, more commonly, leveraging the query editor’s ability to filter by labels like job or namespace, you ensure that tenants only see metrics relevant to their environment. This is often achieved by having Prometheus scrape distinct sets of targets for each tenant and then filtering on those unique labels within Grafana.
The next step is to explore provisioning Grafana organizations and data sources using the Grafana provisioning API or configuration files, which is essential for automating this multi-tenant setup at scale.