Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support graphite as a data source #19

Open
jackrr opened this issue May 8, 2020 · 3 comments
Open

Support graphite as a data source #19

jackrr opened this issue May 8, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@jackrr
Copy link
Contributor

jackrr commented May 8, 2020

I'm attempting to migrate to dark. I have several dashboards represented as JSON that include many graphite panels. After some inspection I'm seeing that neither the converter nor grabana has support for graphite as a target.

Despite this arguably being an issue for grabana to add a new graphite target, I'm opening this issue here because I think it may be worth considering solutions alongside grabana for translating yaml dashboard representations to grafana's JSON.

In an ideal world I'd have the ability to specify in my grafanadashboard k8s resource anything I might find in a Grafana dashboard JSON representation and have that work with dark out of the box.

One idea: support an alternative yaml representation that is equivalent to grafana's JSON representation on the grafanadashboard CRD, then transparently send that representation to the grafana API to sync the resource.

I'm very new to dark and grabana, so it's very likely that I'm missing a lot of key information that's leading to my proposal, above. Whatever the right path forward is, I would love to help contribute so that my team can adopt dark!

Just an aside -- I'm really excited about this repo and how it creates the possibility to use git to manage grafana state. Thanks for making it!

@K-Phoen K-Phoen added the enhancement New feature or request label May 26, 2020
@K-Phoen
Copy link
Owner

K-Phoen commented May 26, 2020

Hello!

Thanks for opening this issue and sorry for the delay: completely missed it across all my notifications :|

Definitely +1 on supporting Graphite as target (both in grabana and here). However, I'm not really in favor of allowing anything else but YAML as input for dark: mixing JSON and YAML in k8s manifests would look weird (to say the least) and having JSON would make it quite hard to read/understand/customize the dashboards definitions.
I'll keep this in the back of my mind though and will wait to see if anyone else requests support for grafana's JSON :)

Would you be willing to contribute graphite support to grabana? I could do it but I have no application using it.

Glad you find dark useful!

@jackrr
Copy link
Contributor Author

jackrr commented May 26, 2020

@K-Phoen hello! Thanks for the response. No worries on the delay, I understand that things get busy.

I agree that managing JSON from YAML would be awkward. I think what I'm trying to propose here is subtly different:

One idea: support an alternative yaml representation that is equivalent to grafana's JSON representation on the grafanadashboard CRD, then transparently send that representation to the grafana API to sync the resource.

Under this proposal, the dashboard would be represented as YAML in the CRD, but dark would know to convert that YAML directly to JSON and send it to grafana.

Following this approach we wouldn't need to implement the various features supported by grafana + graphite in golang (this would be the grabana path as I understand it). Instead, this would require calling some kind of YAML --> JSON conversion in on the dark side of things whenever an appropriate configuration flag on the CRD is seen. An added benefit of this approach is that you get all data sources and grafana features out of the box. If the grafana dashboard JSON API supports it, dark supports it in YAML, too.

As far as I understand it, this approach would provide the full grafana featureset within dark without needing to write golang code.

My motivation for proposing this approach over grabana is that I already have a fairly mature set of dashboards that exercise a variety of graphite features. Needing to implement all those features in grabana in order to migrate to dark I think is a non-starter. We may also wish to add additional data-sources as well, such as PostgreSQL, which would become a much harder operation if we needed to implement a translation layer for that in golang as well.

What downsides do you foresee with this approach?

@glittershark
Copy link

Just wanna chime in to say that yaml is a strict superset of JSON, so any valid JSON is also valid yaml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants