Allow setting an offset on aggregation set transformations
Move optionalOffset into recording-rules directory
Seems like a more logical place if we're going to be reusing it for aggregation-set transformations as well.
Separate upscaling and aggregation set filtering
Separating the 2 responsabilities in 2 files makes it easier to follow what methods are coupled and which aren't.
I also (personally) think that calling something a generic "helper" is a bit of a smell. So here we are...
Set an offset on aggregation set transformations
This sets an offset for aggregation set transformations: When an aggregation set is chained on top of a previous one, an offset can also be added to those recording rules.
This applies this to the metrics that influence the error budgets for stage groups and the general Service Level Availability of GitLab.com.
The affected aggregation sets are:
- compontentSLIs, sourced from promSourceSLIs (prometheus): used for alerting and service dashboards. This will make alerts less noisy and dashboards less jittery
- serviceSLIs, sourced from promSourceSLIs (prometheus): used for the service level availability of GitLab.com, and the main panels on the service overview dashboards.
- serviceComponentStageGroupSLIs, sourced from the featureCategorySLIs (prometheus): used for the error budgets for stage group's main calculation over long ranges. This should stabilize the error budgets for stage groups a bit already: It deals with most of the timing mismatches. It does not yet deal with missing metrics (numerator missing, while the denominator is not).
- stageGroupSLIs, sourced from featureCategorySLIs (prometheus): Used for the panels on the error budeget dashboard for stage groups, but not in any of the calculations.