* 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>
* feat: preinstall_sync config - process and installation logic
* ref: add preinstall_sync list to preinstalled plugins of frontendsettings
* fix: conf blank line for sections
* ref: remove plugins async flag, and rename PreinstallPlugins
* docs: default installed plugin list