* Recusively load nodes, and insert into tree
* Remove console.logs
* Simply functions
* Always show recent scopes category
* Fix issues with parent node remaining in URL
* Always display recent scopes
* Make sure chdilren are loaded when collapsing
* Add test cases for expanded items and imrpove a11y markup
* Remove recent scopes always showing and update tests
* Fix linting issue
* Move insertPathNodesIntoTree to treeUtils
* Add test for insertPathNodesIntoTree
* Remove comment
* also disable incremental querying when the dashboard is public
* add tests for disabling incremental querying if public dashboards are being used
* move public dashboard check earlier
* adding some logs to better understand what might be happening
* only focus this PR on improve logging in finalizer handling
* debug log before calling finalizers
* working on finalizers
* removing last todos, adding unit tests
* better use SupportedFinalizers name
* addressing comments
* wip: fix tests and add delete error in status
* chore: codegen
* chore: codegen openapi
* Merge remote-tracking branch 'origin/main' into provisioning-finalisers-fix-2
* update frontend client
* fix: errors in testing
* fix: breaking test
---------
Co-authored-by: Daniele Ferru <daniele.ferru@grafana.com>
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
- Fix metricEditorMode logic to match frontend hasOwnProperty behavior
- Fix metricQueryType to only set when property doesn't exist
- Fix statistics processing to handle all types like frontend does
- Fix null statistic handling to match frontend behavior
- Fix object string representation to match JavaScript behavior
- Add comprehensive test coverage for all CloudWatch migration scenarios
- Achieve 100% backend-frontend consistency for v34 migration
* Fix v34 CloudWatch migration backend-frontend inconsistencies
- Fix metricEditorMode logic to match frontend hasOwnProperty behavior
- Fix metricQueryType to only set when property doesn't exist
- Fix statistics processing to handle all types like frontend does
- Fix null statistic handling to match frontend behavior
- Fix object string representation to match JavaScript behavior
- Add comprehensive test coverage for all CloudWatch migration scenarios
- Achieve 100% backend-frontend consistency for v34 migration
* Improve v34 CloudWatch migration test coverage
- Add targeted tests for hasOwnProperty logic coverage
- Add comprehensive getSuffixForStat coverage (all data types)
- Add generateNextRefId double letter generation tests
- Simplify test cases while maintaining full coverage
- Achieve 93%+ coverage on all critical v34 functions
- Remove redundant test cases for better maintainability
* Clean up v34 CloudWatch migration code
- Remove unnecessary comments and documentation
- Simplify function signatures and logic
- Maintain functionality while improving readability
- Keep essential logic intact with cleaner code
* Only remove unnecessary comments
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.
Ryan McKinley
Mariell Hoversholm
Will Browne
Gareth
Tobias Skarhed
Jean-Philippe Quéméner
Alexander Zobnin
Stephanie Hingtgen
Paul Marbach
Sonia Aguilar
Drew Slobodnjak
Andrej Ocenas
Todd Treece
Adela Almasan
Jocelyn Collado-Kuri
Tania
Matheus Macabu
Zoltán Bedi
Jara Suárez de Puga GarcíaandIsabel Matwawana
Tom Ratcliffe
Piotr Jamróz
Misi
Costa Alexoglou
Anna Urbiztondo
Sofia Papagiannaki
Alexander Akhmetov
Alexa Vargas
Ivan Ortega Alba
Seunghun Shin
maicon
grafana-pr-automation[bot]andgithub-actions[bot]
Dave Henderson