Alertmanager can't be run within a single binary deployment

[jtlisi]

Currently it is not possible to enable the alertmanager module when cortex is run as a single binary. This is caused by conflicts under the /api/prom route.

One option I would like to suggest to rectify this change is updating the routing scheme for the alertmanager to fall under /alertmanager. I think this format would make more sense overall. I also think the prometheus api should exist under /prometheus. I think this naming scheme would make more sense for two reasons:

1. /api/prom/api/* routes seem clunky to me with the repetition of api
2. /<service>/api/* provides a sensible api scheme that reflects the underlying endpoints. This would also allow for endpoints with the same routes to exist in the same binary. For instance both the alertmanager and prometheus api have a /api/v1/alerts endpoint.

The alternative would be matching /api/prom with a /api/alert route, or something along those lines. I think either approach would work. Although I think the /alertmanager route prefix seems better to me.

[pracucci]

One option I would like to suggest to rectify this change is updating the routing scheme for the alertmanager to fall under /alertmanager. I think this format would make more sense overall. I also think the prometheus api should exist under /prometheus.

I would agree with you if this wouldn't be a breaking change. Given this is a breaking change which doesn't just impact Cortex but also its clients (ie. Grafana config), I've some doubts about it.

The alternative would be matching /api/prom with a /api/alert route, or something along those lines. I think either approach would work.

Following up on this alternative solution, an option may be just split the HTTP prefix config into:

• -http.prometheus-prefix (defaults to /api/prom)
• -http.alertmanager-prefix (defaults to be decided)

The breaking change would be in the the config option name, but not its default value, and would allow users to customize it and have the alertmanager running along with the other components in a single binary setup.

I understand it's not ideal, but the breaking change should be softer.

[bboreham]

It's not a breaking change if the default under -target=alertmanager retains the existing route in parallel with the new way.

[pracucci]

if the default under -target=alertmanager retains the existing route in parallel with the new way.

If we retain the existing rule in parallel with the new one, how do we solve the original problem:

Currently it is not possible to enable the alertmanager module when cortex is run as a single binary. This is caused by conflicts under the /api/prom route.

[bboreham]

By having different defaults in single-binary mode.

[pracucci]

By having different defaults in single-binary mode.

Not sure about this. Looks a bit confusing have different defaults whether you run Cortex in single binary mode or microservices.

[bboreham]

This seems to be the season for breaking changes: party on.

[stale]

This issue has been automatically marked as stale because it has not had any activity in the past 60 days. It will be closed in 15 days if no further activity occurs. Thank you for your contributions.

[pracucci]

@jtlisi Is this still valid?