Alertmanager: Support uploading Grafana Alertmanager Configuration an… #6682
Conversation
…d State Grafana's Alertmanager and Mimir Alertmanager are configured differently but have the same set of upstream components running except receivers. We'd like to enable Grafana to use the Mimir Alertmanager as a backend when Grafana is run with certain configuration so that Grafana can stop leveraging its internal Alertmanager. One of the first steps in this direction is to allow the Mimir Alertmanager to store two things: 1. Grafana's Alertmanager Configuration 2. Grafana's Alertmanager State (Notification log and Silences) This PR, setups up two sets of APIs to allow the Mimir the Mimir Alertmanager to support Grafana in this migration path. One for CRUDing the configuration and one for CRUDing the set of States. Although these APIs are per tenant, they are not meant to be called by tenants and are experimental.
Signed-off-by: gotjosh <[email protected]>
gotjosh
force-pushed
the
gotjosh/state-config-grafana
branch
from
663a0ae to
36c3cee
Compare
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
|
@dimitarvdimitrov, can I get you to quick skim on what I'm doing here to ensure I'm not doing anything stupid (particularly with the feature flag stuff)? We've already tested this end to end in dev and it does what we need it to do (for now, as we'll keep expanding on it) and all the context you need to understand the reasoning is in the description. @santihernandezc, this is now ready for review. |
Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
There was a problem hiding this comment.
LGTM, I left a couple of suggestions & questions. The one for the bucket implementation in bucket_client.go is the major one, the rest are mostly minor.
I suspect that we'd want to update the HTTP API docs at some point too. Perhaps when this is moved out of experimental state?
- Rename created at and default fields to clarity - Move the feature flag from the API level to the Alertmanager level - Add missing doc strings for some functions Signed-off-by: gotjosh <[email protected]>
I have added a task to https://github.com/grafana/alerting-squad/issues/566 to make sure we don't forget. |
Signed-off-by: gotjosh <[email protected]>
…eractions and add tests to ensure integrity. Signed-off-by: gotjosh <[email protected]>
Signed-off-by: gotjosh <[email protected]>
…d State
Grafana's Alertmanager and Mimir Alertmanager are configured differently but have the same set of upstream components running except receivers.
We'd like to enable Grafana to use the Mimir Alertmanager as a backend when Grafana is run with certain configuration so that Grafana can stop leveraging its internal Alertmanager.
One of the first steps in this direction is to allow the Mimir Alertmanager to store two things:
This PR, setups up two sets of APIs to allow the Mimir Alertmanager to support Grafana in this migration path. One for CRUDing the configuration and one for CRUDing the set of States.
Although these APIs are per tenant, they are not meant to be called by tenants and are experimental.
What this PR does
Which issue(s) this PR fixes or relates to
All the tasks are documented in https://github.com/grafana/alerting-squad/issues/566
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX].about-versioning.mdupdated with experimental features.