Skip to content

Commit 39729ef

Browse files
committed
proposal for supporting aggregation functions for analysis values
Signed-off-by: Florian Bacher <[email protected]>
1 parent ddbcd5e commit 39729ef

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# KEP 97 Support Aggregation functions in AnalysisValueTemplate
2+
3+
## Motivation
4+
5+
Currently, only the `KeptnMetrics` CRD supports the use of aggregation functions
6+
(see [here](https://github.com/keptn/lifecycle-toolkit/blob/5fac158a7ffed67f7502fe03683138d717ea1acd/metrics-operator/api/v1beta1/keptnmetric_types.go#L76)).
7+
Supporting the same aggregation functions might also be useful for `AnalysisValueTemplates` as well,
8+
to better support queries that return multiple data points of a time series.
9+
This way, the provider returning the results for the AnalysisValueTemplate can check whether
10+
there are multiple data points in the result for the query and apply the aggregation function in that case.
11+
12+
## Proposed Design
13+
14+
The proposal is to extend the specification of the `AnalysisValueTemplates` with an `spec.aggregation` field,
15+
similar to what is available in the `KeptnMetric` (see [specification](https://keptn.sh/latest/docs/reference/api-reference/metrics/v1beta1/#rangespec)).
16+
Using this field, the metrics operator can inspect the result for an analysis value returned by a metrics provider.,
17+
and, if the aggregation function has been defined, use this function to aggregate the returned result if this is
18+
an array of multiple values, as opposed to a single value.
19+
20+
## Benefits
21+
22+
- Unified way of defining aggregation functions for query results containing multiple time series data points
23+
- More flexibility in terms of which queries can be used for each provider
24+
25+
## Open Questions
26+
27+
One argument that might speak against this feature is that usually monitoring provider
28+
APIs support aggregation functions on their end already,
29+
such as e.g. [DQL](https://docs.dynatrace.com/docs/platform/grail/dynatrace-query-language/functions#aggregation-functions),
30+
so it might be sufficient to adapt queries for AnalysisValueTemplates to make use of the monitoring provider's aggregation capabilities.
31+
32+
## References
33+
34+
See the following Github discussion for more context: https://github.com/keptn/lifecycle-toolkit/issues/2650#issuecomment-1906038916

0 commit comments

Comments
 (0)