|
|
|
|
|
by chris11
2346 days ago
|
|
Thanks a lot, I'll check that out. I did notice that there were some third party libraries that added functionality that I wanted, but it is nice to see a library from Grafana. I would really like first class support for templating on Grafana though. My desired workflow would be to use github for the templates source of truth. Then a dsl on Grafana's end would regenerate the actual config whenever the template was changed. The web editor could provide a fallback method of making changes if it could commit to source control. For instance if I saw a cool demo for graph functionality online I could implement it in the UI and then dig into the autogenerated commit in git. That userflow usually works really with teamcity and their kotlin dsl. Edit: Teamcity gets around the style issues of autogenerated code by submitting changes from the UI as patches. First the kotlin dsl is run on the base config, then patches are applied. That way you are able to rewrite an autogenerated project config in the style and approach you want, and any UI generated changes will be limited to one folder. |
|
General:
1. We run everything on Kubernetes
2. We configure it using Tanka, keep all Jsonnet in git
3. Changes are done using PullRequest
---
Grafana (the software) related:
1. We use provisioning: https://grafana.com/docs/grafana/latest/administration/provi.... This means dashboards are kept in .json files on the filesystem and loaded on startup
2. Those dashboard json files are ConfigMaps
3. Those ConfigMaps are created using Tanka
4. The content of those ConfigMaps is created using grafonnet-lib
This means, our dashboards are source-controlled! A change to a dashboard is reviewed, merged and automatically deployed (ConfigMap is changed, Grafana restarted, picks that up and done!)
---
Caveats:
- Edit dashboard in Grafana won't work anymore
- You need to mess with files - BUT this might change in the future, Jsonnet might become integrated to Grafana. Stay tuned :D