Before enabling TSDB some of visualisations were using sum as an aggregation formula.
Example: One of the visualizations used the formula (sum(kubernetes.apiserver.request.duration.up.sum)/sum(kubernetes.apiserver.request.duration.up.count))/1000. The field kubernetes.apiserver.request.duration.up.* has 8 different labels, and we used to have it broken down by the kubernetes.apiserver.request.resource.
Both these metrics used in the formula are of type counter. Since now sum is not supported aggregation for counter, it should be changed to either last_value or max aggregation. However, we cannot reproduce the same visualization - request duration per resource - with these aggregations, since it is not possible to cluster the data according to a specific label.
Affected visualizations were removed in #617.
Few options:
- we split the visualization by the 8 fields
- BUT: it will overwhelm the visualization and might be not informative
- BUT2: maximum are supported 4 fields for breaking down
- rethink those visualizations, come up with different representation
- re-discuss support of
sum (?)
- drop those visualizations
Before enabling TSDB some of visualisations were using
sumas an aggregation formula.Example: One of the visualizations used the formula
(sum(kubernetes.apiserver.request.duration.up.sum)/sum(kubernetes.apiserver.request.duration.up.count))/1000. The fieldkubernetes.apiserver.request.duration.up.*has 8 different labels, and we used to have it broken down by thekubernetes.apiserver.request.resource.Both these metrics used in the formula are of type
counter. Since nowsumis not supported aggregation forcounter, it should be changed to eitherlast_valueormaxaggregation. However, we cannot reproduce the same visualization -request duration per resource- with these aggregations, since it is not possible to cluster the data according to a specific label.Affected visualizations were removed in #617.
Few options:
sum(?)