* Provisioning: Preserve in progress job data
* Refactor code and cover more situations
* Fix linting
* Fix issue with remove path operation for started time
* Cleanup
* prettier
---------
Co-authored-by: Roberto Jimenez Sanchez <roberto.jimenez@grafana.com>
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
* Set the log group name when executing log queries from the frontend
* Add helper for a data source instance to check if its a monitoring account
* Execute log queries with log group identifiers only for monitoring account queries
* fix cloudwatch datasource.ts tests
* remove unneeded check
* annotation legacy store with api server, read only
* Add a feature flag for annotations app
* implement list filters
* annotations are not addressable by ID for read operations
* fix registry apps test
* add ownership for an app
* disable linter
* typo, of course
* fix go workspace
* update workspace
* copy annotation app in dockerfile
* update workspace
---------
Co-authored-by: Tania B. <10127682+undef1nd@users.noreply.github.com>
* cleanup
* library panel via search
* test cleanup
* merge main
* add FindDashboards mock
* no matching dashbaords should return empty
* do not alllow name and libraryPanel query
* fix: delete folders using postorder
* chore: use helper function and do not add method to Folder store
- addresses other review comments fixing log messages and cleans up the unit tests
* chore: run library element tests on modes 2,3,5 only
* chore: adjust to folder.SortByPostorder(folders []*Folder)
* chore: run library panels tests in mode 2,3,5 only
* chore: run tests in all modes and increase timeout
- adjusting the modes and tweaking configs will be done separately
* fix: delete subfolder dangling panels and error if used
* chore: add observation about library panel DeleteInFolders
- logs folders UIDs on DeleteInFolders error
* chore: add integration test for blocking library panel deletion and handling dangling library panels
* chore: fix integration test on mode 4 and 5
Run the app runner in a goroutine in the post-start hook, as the '/readyz' endpoint for the API server waits for a non-nil error response from the post-start hook to mark it as ready.
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
