Closed andrewazores closed 2 weeks ago
Actually, it seems that the sub-dashboard does somehow pick up on additional classes that are not hardcoded already - though I'm not really sure how. Need to investigate more into variable templating and things, I think.
Actually, it seems that the sub-dashboard does somehow pick up on additional classes that are not hardcoded already - though I'm not really sure how. Need to investigate more into variable templating and things, I think.
I remember (vaguely) this is indeed done using Grafana variables, which calls the data-source /search
endpoint:
https://github.com/grafana/simple-json-datasource?tab=readme-ov-file#search-api. This variable is then templated into the panel query ${objectClass}
.
Ah thanks @tthvo , I had figured out the variable templating bit but the /search
hint helped me fix something else I was doing wrong :-)
See #12
Currently, the sub-dashboard that splits out object allocations into separate panels for different classes does so by simply containing a hardcoded list of classes that are filtered for. For example,
int[]
here:https://github.com/cryostatio/cryostat-grafana-dashboard/blob/ca315d0a3a71ac71079ce743c4d6a9a11e759d55/dashboards/obj_alloc_sample.dashboard.json#L278
However, on the main dashboard, this is done with a wildcard query:
https://github.com/cryostatio/cryostat-grafana-dashboard/blob/ca315d0a3a71ac71079ce743c4d6a9a11e759d55/dashboards/main.dashboard.json#L1178
Is there a way to dynamically generate the sub-dashboard so that it has separate panels for each class in the dataset?
Right now, the main dashboard panel for allocations is complete and accurate to the underlying JFR data, but it can be hard to read because the data is too dense. The sub-dashboard splits it out, reducing the density and making it legible, but it is actually representing incomplete data because any class that is not hardcoded to the layout will not be rendered at all.