Alertmanager: Use /api/v1/alerts instead of /api/v1/alerts/groups

[mxinden]

I have been talking with @fabxc and @brancz about our current Alertmanager API consumption. We decided to keep AlertGroups and AlertBlocks a server-side implementation detail that the UI doesn't need to know of. This would flatten the UI representation of alerts and keep things simple. The UI would just consume /api/v1/alerts and would only know of the entity Alerts not AlertGroups or Blocks.

Steps needed:

1. Implement filter logic for endpoint /alerts like it already exists on /alerts/groups
2. Refactor UI to use /alerts instead of /alerts/groups
3. (Future) Implement groupBy logic for endpoint /alerts

@stuartnelson3 What do you think? As you implemented the filter logic for the /alerts/groups endpoint, is there any show stopper that I overlooked?

[stuartnelson3]

Can't think of any off the top of my head -- the logic just does a match on individual alert objects, so you should be able to re-use it just fine.

[mattbostock]

I find it useful to see the alert groups - I think it'd be a shame to lose that view in the UI.

[mattbostock]

Does this mean that the /api/v1/alerts/groups API endpoint would be removed?

[fabxc]

@mattbostock The current group representation is not accurate either as we flatten the routing tree they are in to reduce the complexity of the representation – giving you a false sense of security as may happen. What we end up with is something structured, yet not representing the actual structure underneath and not giving you the querying flexibility you want either.

Our reasoning is as follow: Prometheus also has labels and follows a very free form approach to exposing them, i.e. you don't retrieve them as you collected them per your scrape configs but just access them via label selectors.
This gives you a lot of power and while it doesn't give you hard relationships, you can trivially query the same thing manually.

So we wanted to follow something similar – you can freely select from all alerts by labels and freely define how you would like to group them. If you get paged from service=X, zone=eu-west, going to the UI and selecting by exactly those labels will give you what you want 99% of the time. So will querying everything and grouping by (service, zone), or querying team=my_team and grouping by (service, severity).
You just get a lot of freedom in what you can query and results being slightly fuzzy, e.g. seeing the occasional alert you didn't really care about, doesn't inhibit your use experience as you can just quickly add another selector.

[mxinden]

@mattbostock In regards to your second comment: So far there are no plans to remove the /api/v1/alerts/groups endpoint.

[mxinden]

@stuartnelson3 @w0rm To prevent duplicate work: Starting on this now.

[mxinden]

Closed by #754