* Alerting: Use a default configuration and periodically poll for new ones
Use a default configuration to make sure we always start the grafana
instance. Then, regularly poll for new ones.
I've also made sure that failures to apply configuration do not stop the
Grafana server but instead keep polling until it is a success.
* add db columns
* Fix deserialisation issue of AlertRule For field (#32848)
* Update to latest alerting-api
Co-authored-by: Sofia Papagiannaki <papagian@users.noreply.github.com>
* Alerting: Cleanup and move legacy to a legacy file
A quick cleanup of the ngalert/api directory, optimising for an easy
removal of what is will be considered legacy at some point. A quick
summary of what's done is:
- Add a prefix `generated` prefix to files that are auto-generated by
our swagger definitions.
- Create a legacy file to place all the legacy API routes implementation
and helpers. Deleting files that where no longer needed after this
move.
- Rename the `lotex` file to `lotex_ruler`
- Adding a couple of comments here and there.
With this, I hope to organise our code in this directory a bit better
given there's a lot going on.
* Return cached alerts for prometheus/api/v1/alerts
* Return not implemented for /prometheus/grafana/api/v1/rules
* Set StartsAt for already alerting states
* Fix tests
* Add validation for grafana recipient
* Alertmanager API implementation (WIP)
* Fix encoding/decoding receiver settings from/to YAML
* Save templates together with the configuration
* update POST to apply latest config
* Alertmanager service enabled by the ngalert toggle
* Silence API integration with Alertmanager
* Apply suggestions from code review
Co-authored-by: gotjosh <josue@grafana.com>
Co-authored-by: Ganesh Vernekar <15064823+codesome@users.noreply.github.com>
* Alerting: Introduce the silencing interface
The operations introduced are:
- Listing silences
- Retrieving an specific silence
- Deleting a silence
- Creating a silence
Signed-off-by: Josue Abreu <josue@grafana.com>
* Add a comment to listing silences
* Update to upstream alertmanager
* Remove copied code from the Alertmanager
* Alerting: Fetch configuration from the database and run a notification
instance
Co-Authored-By: Ganesh Vernekar <15064823+codesome@users.noreply.github.com>
- Takes the conditions property from the settings column of an alert from alerts table and turns into an ng alerting condition with the queries and classic condition.
- Has temp API rest endpoint that will take the dashboard conditions json, translate it to SEE queries + classic condition, and execute it (only enabled in dev mode).
- Changes expressions to catch query responses with a non-nil error property
- Adds two new states for an NG instance result (NoData, Error) and updates evaluation to match those states
- Changes the AsDataFrame (for frontend) from Bool to string to represent additional states
- Fix bug in condition model to accept first Operator as empty string.
- In ngalert, adds GetQueryDataRequest, which was part of execute and is still called from there. But this allows me to get the Expression request from a condition to make the "pipeline" can be built.
- Update AsDataFrame for evalresult to be row based so it displays a little better for now
* AlertingNG: base API implementation
* Pass the interface instead of the base impl
* Ruler mock draft (WIP)
* Update alerting-api dependency
* Improve mock implementation
