Provision dashboards from file in addition to Grafana Dashboards

[aman0019]

Currently dashboards can only be provisioned through their dashboard_id and downloaded from the Grafana Dashboards . It would be nice (and pretty simple to implement) if the dashboards can be supplied as a json file to the playbook

[paulfantom]

You're right. It should be implemented as a part of #30 but right now I don't have time to do this. Feel free to implement it 😄

Grafana even mentions this in their docs: http://docs.grafana.org/administration/provisioning/#dashboards

[aman0019]

So was your plan to scrap how the role is provisioning dashboards altogether and move towards using Grafana's documented way i.e. YML config files in provisioning/dashboards?

[paulfantom]

That's right. However I planned to have both methods for some time since the new method is available only since grafana 5.0

[aman0019]

Yes; also if I understood well if we move towards the YML file provisioning we would need to delay restarting Grafana until after the dashboard tasks are completed since as opposed to the API; YML provisioning files are only picked up at startup. Is that your understanding as well?

[paulfantom]

I haven't tried this method yet, so I am not 100% sure how this is handled by grafana.
In the docs it is said that grafana polls on the specified path and checks for changes. This means that we won't have to restart grafana on every new dashboard, but only when new YML providers file is created or changed.
I would like to limit restarts as much as I can.

[aman0019]

I would like to limit restarts as much as I can.

makes sense

Apologies for asking twenty questions; just want to make sure I get this right. The API does support adding dashboards to folders...what are the benefits to be gained by moving to the 'provisioning by file' method?

[paulfantom]

For example, right now we don't have any method to copy custom dashboards and we rely only on grafana.net. By using 'provsioning by file' we can easily copy dashboards and as a bonus we could use ansible internals for detecting changes.

[aman0019]

Agreed that detecting changes for dashboards provisioned through files is the most obvious benefit. As Grafana's documentation states; the other benefit is that one can push changes whilst Grafana is not running and these would be picked up on startup. However, whilst dashboard JSON files can be added/changed at runtime; the config file that defines dashboard providers would only be processed at startup and as such this needs to be provisioned before Grafana is restarted. Do you agree that we should provision a YAML config file that defines the ansible file dashboard provider before startup? and then we can provision dashboards using files in the dashboard.yml play.

[paulfantom]

Basically this is the same to what I had in mind. However we don't have to do anything before startup as we could apply handler task to restart grafana when dashboard providers are changed. This way we don't have to change order of included files in ansible role and still have dashboards.yml after task which starts grafana.

It would be awesome if grafana could react on SIGHUP to reload its config, this would allow easier provisioning without interrupts.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[guilhermesteinmuller]

Hey there! Pretty good feature would be.

We switched our grafana repo to cloudalchemy recently. In ours, we used to push the dashboards locally.

So, I'd appreciate if you guys could take a look and if thinks is interesting, I can find some time to implement like we used to do :)

[paulfantom]

@guilhermesteinmuller wouldn't it be simpler to use http://docs.grafana.org/administration/provisioning/#dashboards ?

I am open to all contributions!

[guilhermesteinmuller]

Sorry, I didn't pay attention to this.

I will take a look @paulfantom and I would love to contribute. I'll give a position asap! :-D

cheers

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.