What is this feature?
Add a config option to set data source to imported rules when X-Grafana-Alerting-Datasource-UID is not present.
Why do we need this feature?
Currently mimirtool requires passing --extra-headers 'X-Grafana-Alerting-Datasource-UID: {uid}' when used with Grafana. This config option allows to specify a default, which is used when the header is missing, making it easier to use and more similar to the case when it's used with Mimir.
* Default to folder sync only and block new instance sync repositories
- Change default allowed_targets to folder-only in backend configuration
- Modify validation to only enforce allowedTargets on CREATE operations
- Add deprecation warning for existing instance sync repositories
- Update frontend defaults and tests to reflect new behavior
Fixes#619
* Update warning message: change 'deprecated' to 'not fully supported'
* Fix health check: don't validate allowedTargets for existing repositories
Health checks for existing repositories should treat them as UPDATE operations,
not CREATE operations, so they don't fail validation for instance sync target.
* Fix tests and update i18n translations
- Update BootstrapStep tests to reflect folder-only default behavior
- Run i18n-extract to update translation file structure
* Fix integration tests
* Fix tests
* Fix provisioning test wizard
* Fix fronted test
* Short Links: Change default expiration to never expire (-1)
Previously, short links defaulted to expiring after 7 days. This change
updates the default to -1 (never expire) to prevent automatic deletion
of shared dashboard links.
Changes:
- conf/defaults.ini: Set expire_time = -1 and update comment
- conf/sample.ini: Set expire_time = -1 and update comment
- pkg/setting/setting.go: Update MustInt default from 7 to -1
The cleanup logic already handles -1 correctly (only runs when > 0),
so no changes needed there.
This unblocks progress on short URL feature improvements by ensuring
shared links remain accessible indefinitely by default.
* fix go
* update docs / comments
* update missed comment in sample.ini
* Revert "fix go"
This reverts commit e0d099ae31.
* chore: update workspace dependencies
Run 'make update-workspace' to sync Go workspace dependencies.
This updates go.mod and go.sum files to match the current workspace state.
* chore: add modowner for apps/quotas dependency
Assign @grafana/grafana-search-and-storage as owner for apps/quotas
dependency to satisfy modowners CI check.
* Secrets: Refactor data_key_id out of the encoded secure value payload (#111852)
* everything compiles
* tests pass
* remove file included by accident
* add entry to gitignore
* some scaffolding for the migration executor
* remove file
* implement and test the migration
* use xkube.Namespace in our interfaces
* add todo
* update wire deps
* add some logs
* fix wire dependency ordering
* create tests to validate error conditions during migrations
* only run the migration as an MT api server
* formatting issues
* change detection of secrets running as MT server
* add todo
* use more specific initializer flags
* make secrets playwright tests work
* set new properties to true by default
* remove developer mode flag
* fix unit tests
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.
* feat(plugins): add a way to expose core apis only to certain plugins
* review: update naming
* review: update the owners of the feature toggle
* feat: share the restricted apis with extensions
* fix: linters
* feat: remove the `addPanel` api
* chore: fix linting and betterer issue
* tests: use `@ts-expect-error` for more clarity
* Add setting to disable username based brute force login protection
* Use new DisableUsernameLoginProtection setting in tests where appropriate
* Update documentation for other brute force directives
* Avoid unecessary database calls
* Add test cases for username and IP protection settings
* Cloud migrations: store snapshots in the database
* update github.com/grafana/grafana-cloud-migration-snapshot to v1.9.0
* make update-workspace
* use new field name in test
* return error after call to fmt.Errorf
* create methods for readability / fix session deletiong not deleting snapshots
* remove debugging changes
* update sample.ini
* update tests to include OrgID in ListSnapshotsQuery
* lint
* lint
* Update pkg/services/cloudmigration/cloudmigrationimpl/snapshot_mgmt.go
Co-authored-by: Matheus Macabu <macabu@users.noreply.github.com>
* remove TODO
* Update pkg/services/cloudmigration/cloudmigrationimpl/snapshot_mgmt.go
Co-authored-by: Matheus Macabu <macabu@users.noreply.github.com>
* remove one of the debug logs
---------
Co-authored-by: Matheus Macabu <macabu@users.noreply.github.com>
* wip
* docker compose dev setup
* commit new tilt stuff
* move files into own dir
* reset files back to main
* use just one nginx container for both gateway and cdn
* update proxy service name
* make it all work when in subdir
* rename more things
* reset more changes
* fix config
* add makefile command, fix ws upgrade
* add local check script
* tidy
* tidy up, comments, readyme
* codeowners
* change cdn host to localhost to avoid adding host.docker.internal to /etc/hosts
* route POST /login to backend
* Build nginx container with config baked in so it can be live_update-ed
* fix headers
**What is this feature?**
This PR implements a new Prometheus historian backend that allows Grafana alerting to write alert state history as Prometheus-compatible `ALERTS` metrics to remote Prometheus-compatible data sources.
The metric includes a few additional labels:
* `grafana_alertstate`: Grafana's full alert state, more granular than Prometheus.
* `grafana_rule_uid`: Grafana's alert rule UID.
Grafana states are included in the `grafana_alertstate` label also mapped to Prometheus-compatible `alertstate` values:
| Grafana alert state | `alertstate` | `grafana_alertstate` |
|---------------------|-----------------------|-----------------------|
| `Alerting` | `firing` | `alerting` |
| `Recovering` | `firing` | `recovering` |
| `Pending` | `pending` | `pending` |
| `Error` | `firing` | `error` |
| `NoData` | `firing` | `nodata` |
| `Normal` | _(no metric emitted)_ | _(no metric emitted)_ |
Adds a new "Allow as recording rules target" toggle to Prometheus datasource configuration that controls whether the datasource can be selected as a target for writing recording rules.
---------
Co-authored-by: ismail simsek <ismailsimsek09@gmail.com>
Co-authored-by: Konrad Lalik <konradlalik@gmail.com>
Alexander Akhmetov
Roberto Jiménez Sánchez
Laura Fernández
alerting-team[bot]
Nathan Marrs
Matheus Macabu
Gareth
Ieva
Ashley Harrison
Andres Torres
Gabriel MABILLE
Josh Hunt
Andres Martinez Gotor
Esteban Beltran
Michael Mandrus
Hugo Häggmark
Stephanie Hingtgen
Tania
Seunghun Shin
Eric Leijonmarck
Tom Ratcliffe
Levente Balogh
Steffen Baarsgaard
Théo Brigitte
Bruno Abrantes
Aaron Sanders
Chris Chang
Bruno
Vadim Stepanov
Dana Axinte
Chris Hodges