* Alerting: Add expression type to webhook valueString
- Add Type field to NumberValueCapture struct
- Implement AlertQuery.GetExpressionType() method
- Update valueString format to include type information
* Alerting: Add expression type to webhook valueString
- Fix tests
* Alerting: Add expression type to webhook valueString
- Update default annotations in notifier templates to include type field
* Alerting: Add expression type to webhook valueString
- Add type='math' to webhook and email test expectations
Part 2 of adding version messages to the `alert_rule_version` able. This allows
setting the message via a header when using the Prometheus conversion API,
which can be useful for e.g. linking changes back to source control.
* fix: collate rule_group column as utf8mb4_bin
This ensures this column is sorted identically by the database and
golang, which should eliminate issues related to a mismatch in sort
order.
* chore: make test stricter
* fix: also add binary collation for postgres
To better observe and identify performance bottlenecks in the prometheus rules API.
The following spans were added:
- `api.prometheus.RouteGetRuleStatuses`
- `api.prometheus.PrepareRuleGroupStatusesV2`
The `api.prometheus.PrepareRuleGroupStatusesV2` includes attributes to capture the parameters used in the request to help with debugging and performance analysis.
* Deprecating features.IsEnabled
* add one more nolint
* add one more nolint
* Give better hints to devs in the deprecation message of IsEnabledGlobally
* adding more doc strings
* fix linter after rebase
* Extend deprecation message
This adds a `message` column to the `alert_rule_version` table. This follows the
pattern established for dashboards as closely as possible. A new type is
introduced internally for passing the new `message` field around in a type-safe
manner, but doing the same for the API types becomes very messy. In that case, a
new field is added with omitempty.
Note this PR is only:
- The column addition
- The "read" path; API for listing versions
Subsequent PRs will add code to actually set the message when updating rules.
* add support for converting Mimir integrations to Integration
* implement imported config revision
* update service to load staged receivers if configured
* make sure non-Grafana origin cannot be mutated
* set access control metadata for imported origin
* set includeImported from feature flag. Disabled for service used by provisioning
* add tests for new functionality
* add snapshot-based integration test
If an alert rule with an invalid receiver is created it breaks the entire alertmanager configuration rather than preventing the save.
This fixes the issue by erroring on save and apply, and logging invalid receivers only when applying the config after an update.
Introduced in #111838
What is this feature?
This PR implements compressed periodic save for alert state storage, providing a more efficient alternative to regular periodic saves by grouping alert instances by rule UID and storing them using protobuf and snappy compression. When enabled via the state_compressed_periodic_save_enabled configuration option, the system groups alert instances by their alert rule, compresses each group using protobuf serialization and snappy compression, and processes all rules within a single database transaction at specified intervals instead of syncing after every alert evaluation cycle.
Why do we need this feature?
During discussions in PR #111357, we identified the need for a compressed approach to periodic alert state storage that could further reduce database load beyond the jitter mechanism. While the jitter feature distributes database operations over time, this compressed periodic save approach reduces the frequency of database operations by batching alert state updates at explicitly declared intervals rather than syncing after every alert evaluation cycle.
This approach provides several key benefits:
- Reduced Database Frequency: Instead of frequent sync operations tied to alert evaluation cycles, updates occur only at configured intervals
- Storage Efficiency: Rule-based grouping with protobuf and snappy compression significantly reduces storage requirements
The compressed periodic save complements the existing jitter mechanism by providing an alternative strategy focused on reducing overall database interaction frequency while maintaining data integrity through compression and batching.
Who is this feature for?
- Platform/Infrastructure teams managing large-scale Grafana deployments with high alert cardinality
- Organizations looking to optimize storage costs and database performance for alerting workloads
- Production environments with 1000+ alert rules where database write frequency is a concern
The query which fetches alert rules in a paginated manner ordered by `rule_group` can result in strange and inconsistent ordering when the database uses a case-insensitive collation for the `rule_group` column. This can lead to scenarios where rules from different groups are interleaved in the results, making pagination unreliable and the returned number of rule_groups incorrect.
Related to #88990
When creating silences in remote Alertmanager instances, all 4xx errors were treated as 500s.
This change ensures that 4xx errors are properly surfaced as bad payload errors, allowing callers to handle them appropriately.
* remove unused compat functions
* update to alerting module from pr
* replace IntegrationConfig with IntegrationSchemaVersion
* safely resolve a string into integration type
* change usages of integration config
* update alerting module
* replace compat with ones from alerting
* update type references Receiver and Integration to *Status
* update route in provisioning test that is invalid after recent change
* use right type for LINE ingtegration
Alexander Akhmetov
Yuri Tseretyan
Santiago
Seunghun Shin
Steve Simpson
Tito Lins
Alexander Soelberg Heidarsson
William Wernert
Matheus Macabu
Moustafa Baiou
Denis Vodopianov
Dave Henderson
