|
|
|
|
@ -105,9 +105,9 @@ It's also possible to update and delete data sources from the config file. More |
|
|
|
|
|
|
|
|
|
### Dashboards |
|
|
|
|
|
|
|
|
|
We also deprecated the [dashboard.json] in favor of our new dashboard provisioner that keeps dashboards on disk |
|
|
|
|
We also deprecated the `[dashboard.json]` in favor of our new dashboard provisioner that keeps dashboards on disk |
|
|
|
|
in sync with dashboards in Grafana's database. The dashboard provisioner has multiple advantages over the old |
|
|
|
|
[dashboard.json] feature. Instead of storing the dashboard in memory we now insert the dashboard into the database, |
|
|
|
|
`[dashboard.json]` feature. Instead of storing the dashboard in memory we now insert the dashboard into the database, |
|
|
|
|
which makes it possible to star them, use one as the home dashboard, set permissions and other features in Grafana that |
|
|
|
|
expects the dashboards to exist in the database. More info in the [dashboard provisioning docs](/administration/provisioning/#dashboards) |
|
|
|
|
|
|
|
|
|
@ -117,4 +117,4 @@ We are introducing a new identifier (`uid`) in the dashboard JSON model. The new |
|
|
|
|
We are also changing the route for getting dashboards to use this `uid` instead of the slug that the current route and API are using. |
|
|
|
|
We will keep supporting the old route for backward compatibility. This will make it possible to change the title on dashboards without breaking links. |
|
|
|
|
Sharing dashboards between instances becomes much easier since the uid is unique (unique enough). This might seem like a small change, |
|
|
|
|
but we are incredibly excited about it since it will make it much easier to manage, collaborate and navigate between dashboards. |
|
|
|
|
but we are incredibly excited about it since it will make it much easier to manage, collaborate and navigate between dashboards. |
|
|
|
|
|