* 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
* Revert "Alerting: Generate simplified routing routes with old fingerprint function (#111893)"
This reverts commit 0da9d49896.
* Add alertingUseNewSimplifiedRoutingHashAlgorithm flag
* Alerting: Add feature toggle to use the old simplified routing hash generation
What is this feature?
This PR implements a jitter mechanism for periodic alert state storage to distribute database load over time instead of processing all alert instances simultaneously. When enabled via the state_periodic_save_jitter_enabled configuration option, the system spreads batch write operations across 85% of the save interval window, preventing database load spikes in high-cardinality alerting environments.
Why do we need this feature?
In production environments with high alert cardinality, the current periodic batch storage can cause database performance issues by processing all alert instances simultaneously at fixed intervals. Even when using periodic batch storage to improve performance, concentrating all database operations at a single point in time can overwhelm database resources, especially in resource-constrained environments.
Rather than performing all INSERT operations at once during the periodic save, distributing these operations across the time window until the next save cycle can maintain more stable service operation within limited database resources. This approach prevents resource saturation by spreading the database load over the available time interval, allowing the system to operate more gracefully within existing resource constraints.
For example, with 200,000 alert instances using a 5-minute interval and 4,000 batch size, instead of executing 50 batch operations simultaneously, the jitter mechanism distributes these operations across approximately 4.25 minutes (85% of 5 minutes), with each batch executed roughly every 5.2 seconds.
This PR provides system-level protection against such load spikes by distributing operations across time, reducing peak resource usage while maintaining the benefits of periodic batch storage. The jitter mechanism is particularly valuable in resource-constrained environments where maintaining consistent database performance is more critical than precise timing of state updates.
* update tests to assert against snapshot
* remove channel_config package replaced by schemas from alerting module
* update references to use new schema
* make validateReceiver private
* make functions and type alias private
* move EncryptedReceivers and DecryptedReceivers to notifier package
to reduce exposure of definitions package via legacy_storage
* return receivers with Grafana origin after create\update
* add tests for ConfigRevision methods
* generate schema for mimir integrations from schema on front-end
* review and fix the settings
* Update GetAvailableNotifiersV2 to return mimir as v0
* add version argument to GetSecretKeysForContactPointType
* update TestGetSecretKeysForContactPointType to include v0
* add type alias field to contain alternate types that different from Grafana's
* add support for msteamsv2
* update ConfigForIntegrationType to look for alternate type
* update IntegrationConfigFromType to use new result of ConfigForIntegrationType
* add reference to parent plugin to NotifierPluginVersion to allow getting plugin type by it's alias
* add tests to ensure consistency
* make API response stable
* add tests against snapshot + omit optional fields
* add origin to receiver
* populate origin of the receiver
* set CanUse to false if origin is not Grafana
* set provenance if origin is imported
* set Grafana origin by default in conversion API
* set canUse annotation
* reject update\delete operations on resources with origin other than Grafana
* fail to create with wrong origin
This lets the prometheus api respect NoGroup query logic and treat non-grouped rules consistently.
Co-authored-by: William Wernert <william.wernert@grafana.com>
Rules created in the new api makes the rule have no group in the database, but the rule is returned in the old group api with a sentinel group name formatted with the rule uid for compatiblity with the old api.
This makes the UI continue to work with the rules without a group, and the ruler will continue to work with the rules without a group.
Rules are not allowed to be created in the provisioning api with a NoGroup sentinel mask, but NoGroup rules can be manipulated through both the new and old apis.
Co-authored-by: William Wernert <william.wernert@grafana.com>
* Replace remaining calls to testing.Short where possible.
* Update style guide.
* Revert change in TestAlertmanager_ExtraDedupStage, as it doesn't work.
* Make TestAlertRulePostExport into integration test.
tlsConfig -> tls_config
hmacConfig -> hmac_config
tls_config export still does not match TF provider, as the provider currently
treats tls_config as a schemaless map. Once this is improved, they will now
match.
* make legacy store expose only model.Receiver
* use integration as provenance type provider
* use revision RenameReceiverInRoutes
* introduce function GetReceiversNames in config revision
---------
Co-authored-by: Matthew Jacobson <matthew.jacobson@grafana.com>
