stackit-dev-tools/terraform-provider-stackitprivatepreview
3
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

feat(observability): continue attribute for instance -> alert config (#993)

Browse source
This commit is contained in:
Patrick Koss 2025-09-19 17:30:13 +02:00 • committed by GitHub
parent 07f6c5fbce
commit f0438e888c
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
6 changed files with 45 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

1
docs/data-sources/observability_instance.md
View file

@ -145,6 +145,7 @@ Read-Only:
Read-Only:
- `continue` (Boolean) Whether an alert should continue matching subsequent sibling nodes.
- `group_by` (List of String) The labels by which incoming alerts are grouped together. For example, multiple alerts coming in for cluster=A and alertname=LatencyHigh would be batched into a single group. To aggregate by all possible labels use the special value '...' as the sole label name, for example: group_by: ['...']. This effectively disables aggregation entirely, passing through all alerts as-is. This is unlikely to be what you want, unless you have a very low alert volume or your upstream notification system performs its own grouping.
- `group_interval` (String) How long to wait before sending a notification about new alerts that are added to a group of alerts for which an initial notification has already been sent. (Usually ~5m or more.)
- `group_wait` (String) How long to initially wait to send a notification for a group of alerts. Allows to wait for an inhibiting alert to arrive or collect more initial alerts for the same group. (Usually ~0s to few minutes.)

1
docs/resources/observability_instance.md
View file

@ -157,6 +157,7 @@ Required:
Optional:
- `continue` (Boolean) Whether an alert should continue matching subsequent sibling nodes.
- `group_by` (List of String) The labels by which incoming alerts are grouped together. For example, multiple alerts coming in for cluster=A and alertname=LatencyHigh would be batched into a single group. To aggregate by all possible labels use the special value '...' as the sole label name, for example: group_by: ['...']. This effectively disables aggregation entirely, passing through all alerts as-is. This is unlikely to be what you want, unless you have a very low alert volume or your upstream notification system performs its own grouping.
- `group_interval` (String) How long to wait before sending a notification about new alerts that are added to a group of alerts for which an initial notification has already been sent. (Usually ~5m or more.)
- `group_wait` (String) How long to initially wait to send a notification for a group of alerts. Allows to wait for an inhibiting alert to arrive or collect more initial alerts for the same group. (Usually ~0s to few minutes.)