feat(datasource-plugin): add support for label queries

[kolesnikovae]

The implementation and query syntax is similar to the Prometheus datasource for convenience: https://grafana.com/docs/grafana/latest/datasources/prometheus/template-variables/#use-query-variables

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
webapp/public/assets/app.js	1006.86 KB (0%)	20.2 s (0%)	4 s (+6.72% 🔺)	24.1 s
webapp/public/assets/app.css	19.9 KB (0%)	398 ms (0%)	0 ms (+100% 🔺)	398 ms
webapp/public/assets/styles.css	9.6 KB (0%)	192 ms (0%)	0 ms (+100% 🔺)	192 ms
packages/pyroscope-flamegraph/dist/index.js	632.77 KB (0%)	12.7 s (0%)	2.1 s (+39.19% 🔺)	14.7 s
packages/pyroscope-flamegraph/dist/index.node.js	633.47 KB (0%)	12.7 s (0%)	744 ms (+4.68% 🔺)	13.5 s
packages/pyroscope-flamegraph/dist/index.css	8.11 KB (0%)	163 ms (0%)	0 ms (+100% 🔺)	163 ms

[github-actions]

Flamegraph.com report

pyroscope-oss.alloc_objects.json

See in flamegraph.com

pyroscope-oss.alloc_space.json

See in flamegraph.com

pyroscope-oss.cpu.json

See in flamegraph.com

pyroscope-oss.goroutines.json

See in flamegraph.com

pyroscope-oss.inuse_objects.json

See in flamegraph.com

pyroscope-oss.inuse_space.json

See in flamegraph.com

Created by Flamegraph.com Github Action

[github-actions]

Flamegraph.com report

pyroscope-oss.frontend.cpu.json

See in flamegraph.com

pyroscope-oss.frontend.inuse_objects.json

See in flamegraph.com

pyroscope-oss.frontend.inuse_space.json

See in flamegraph.com

Created by Flamegraph.com Github Action

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (4129a30) 63.28% compared to head (5e6cfc7) 63.28%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1877   +/-   ##
=======================================
  Coverage   63.28%   63.28%           
=======================================
  Files         175      175           
  Lines        5912     5912           
  Branches     1587     1587           
=======================================
  Hits         3741     3741           
  Misses       2162     2162           
  Partials        9        9           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[kolesnikovae]

@eh-am if you have a chance, please give the PR a look – after our discussion, I made an attempt to implement label queries, and I wonder if it is sufficient for our needs

[eh-am]

This is pretty sweet!

Kapture.2023-02-24.at.20.18.53.mp4

One thing I find necessary though is to be able to choose no tag. In the example above I may want to look at simple.app.cpu{}, it would be nice to have some kind of catch all using .*, but that would require updating the endpoints etc I assume.

One last thing is that we can't forget about updating the README with this new functionality.

[eh-am]

One thing I find necessary though is to be able to choose no tag. In the example above I may want to look at simple.app.cpu{}, it would be nice to have some kind of catch all using .*, but that would require updating the endpoints etc I assume.

One idea is to in the datasource, if both sides of the = are empty, to just discard it altogether? That way, if you select the 2 variables to be an empty value, it will be translated myapp{=} -> myapp{}

[kolesnikovae]

One thing I find necessary though is to be able to choose no tag. In the example above I may want to look at simple.app.cpu{}, it would be nice to have some kind of catch all using .*, but that would require updating the endpoints etc I assume.

One idea is to in the datasource, if both sides of the = are empty, to just discard it altogether? That way, if you select the 2 variables to be an empty value, it will be translated myapp{=} -> myapp{}

Yeah, also was thinking about this. But honestly I doubt variable substitution mechanism in Grafana is good/designed for this – I can picture one may want to use multiple labels, use different operators, have a sophisticated logic of label dependencies, etc. In general, I can't even find a good example when to use label_names. I think we should implement a proper query builder instead.

I was playing with various scenarios and discovered that repeating panel or row does not seem to work as expected (both for apps and label values) – when I specify multiple values, our datasource gets an array of values:

The variable:

The panel:

What do you think? Is it what we should handle in our panel plugin / query editor or I did miss something?

[kolesnikovae]

Ok, I figured out how to make it work with multi-variable choice: