Send sloth slos to grafana cloud

[QuentinBisson]

Before adding a new alerting rule into this repository you should consider creating an SLO rules instead.
SLO helps you both increase the quality of your monitoring and reduce the alert noise.

• How to create a SLO rule: https://github.com/giantswarm/sloth-rules#how-to-create-a-slo
• Documentation: https://intranet.giantswarm.io/docs/monitoring/slo-alerting/

---

Towards: https://github.com/giantswarm/giantswarm/issues/31098
This PR creates aggretation for sloth slos so we do not have too high cardinality based on pod, node and instance labels for instance. I will try them out on a test installation first to see the load

Checklist

• Update CHANGELOG.md
• Add Unit tests
• Follow Alert structure
• Consider creating a dashboard (guidelines) (if it does not exist already) to help oncallers monitor the status of the issue.
• Request review from oncall area, as well as team (e.g: oncall-kaas-cloud GitHub group).

[QuentinBisson]

@giantswarm/team-atlas I would think we can do without the 3d , 1d and so on and only use the 5m ones?

[lyind]

Didn't review the queries in detail, but the recorded series LGTM.

I don't know for sure, why other sli_error:ratio_rate* series except aggregation:slo:sli_error:ratio_rate5m would be needed.

[QuentinBisson]

It actually makes sensé, i'll remove them

[QuantumEnigmaa]

LGTM