clustering: `--cluster.advertise-address` implicitly expects an IP address and does not let one use a hostname

What did you do?

I followed the documentation at https://prometheus.io/docs/alerting/latest/high_availability/#configuration and set --cluster.advertise-address to be hostname:443 (where hostname really is the fqdn of the machine).

What did you expect to see?

I would expect alertmanager to use that hostname to advertise to other peers.

I'm trying to configure two alertmanager instances in different PoPs (for better availability on major network outages). Thus, I want them to talk using TLS for the gossip. I could use IP addresses directly but it feels annoying and brittle. I cannot let alertmanager autodiscover the advertise address since there is no private IP on those hosts.

Note that I've already mentioned in #1271 that the documentation is wrong and needs fixing. But this issue is more about the fact that I think requiring an IP address for that option should get changed to permit using a hostname

What did you see instead? Under which circumstances?

The service fails to start and issues a log message about failing to parse an address on hostname

I dug around in the source code and found out that the option gets passed on to net.ParseIP here, which causes the parsing errors: https://github.com/prometheus/alertmanager/blob/main/cluster/advertise.go#L38-L42

To fix this we would just need to add some call to resolve the option to an IP in the same function if the option does not look like an IP address.

System information

Debian trixie

Alertmanager version

alertmanager, version 0.28.1+ds (branch: debian/sid, revision: 0.28.1+ds-1)
  build user:       team+pkg-go@tracker.debian.org
  build date:       20250309-13:50:43
  go version:       go1.24.1
  platform:         linux/amd64
  tags:             unknown

installed from debian archive

Alertmanager configuration file

Prometheus version

Prometheus configuration file

Logs

~~~
Mar 25 16:43:06 prometheus-04 prometheus-alertmanager[436770]: time=2026-03-25T16:43:06.017Z level=INFO source=main.go:191 msg="Starting Alertmanager" version="(version=0.28.1+ds, branch=debian/sid, revision=0.28.1+ds-1)"
Mar 25 16:43:06 prometheus-04 prometheus-alertmanager[436770]: time=2026-03-25T16:43:06.017Z level=INFO source=main.go:192 msg="Build context" build_context="(go=go1.24.1, platform=linux/amd64, user=team+pkg-go@tracker.debian.org, date=20250309-13:50:43, tags=unknown)"
Mar 25 16:43:06 prometheus-04 prometheus-alertmanager[436770]: time=2026-03-25T16:43:06.017Z level=WARN source=cluster.go:178 msg="couldn't deduce an advertise address: failed to parse advertise addr 'prometheus-04.torproject.org'" component=cluster
Mar 25 16:43:06 prometheus-04 prometheus-alertmanager[436770]: time=2026-03-25T16:43:06.018Z level=INFO source=cluster.go:241 msg="using TLS for gossip" component=cluster
Mar 25 16:43:06 prometheus-04 prometheus-alertmanager[436770]: time=2026-03-25T16:43:06.019Z level=ERROR source=main.go:259 msg="unable to initialize gossip mesh" err="create memberlist: Failed to get final advertise address: failed to parse advertise address \"prometheus-04.torproject.org\""
~~~

Start with cluster/advertise.go at the net.ParseIP handling referenced in the issue, then trace how the advertise address is passed into the gossip setup. Verify the expected behavior for a hostname with a port and confirm that Alertmanager starts and advertises successfully when the address is not a literal IP.