service/prometheus.md

@@ -72,7 +72,7 @@ A simple query you can try is to pick any metric in the list and click
 `Execute`. For example, [this link][] will show the 5-minute load
 over the last two weeks for the known servers.
 
-[this link]: https://prometheus1.torproject.org/graph?g0.range_input=2w&g0.expr=node_load5&g0.tab=0
+[this link]: https://prometheus.torproject.org/graph?g0.range_input=2w&g0.expr=node_load5&g0.tab=0
 
 The Prometheus web interface is crude: it's better to use [Grafana][]
 dashboards for most purposes other than debugging.
@@ -1695,7 +1695,7 @@ label here:
     job="gitlab-workhorse"
 
 This corresponds to a `job` field in the Prometheus configuration. On
-the `prometheus1` server, for example, we can see this in
+the `prometheus-03` server, for example, we can see this in
 `/etc/prometheus/prometheus.yml`:
 
 ```yaml
@@ -2864,7 +2864,7 @@ timers that write to the node exporter text file collector.
 
 Those are the actual services monitored by Prometheus.
 
-#### Internal server (`prometheus1`)
+#### Internal server (`prometheus-03`)
 
 The "internal" server scrapes all hosts managed by Puppet for
 TPA. Puppet installs a [`node_exporter`][] on *all* servers, which
@@ -3325,8 +3325,8 @@ a stopgap measure.
 A secondary Prometheus server (`prometheus2`) was setup with stronger
 authentication for service admins. The rationale was that those
 services were more privacy-sensitive and the primary TPA setup
-(`prometheus1`) was too open to the public, which could allow for
-side-channels attacks.
+(at the time `prometheus1`, now replaced by `prometheus-03`) was too open to the
+public, which could allow for side-channels attacks.
 
 Those tools has been used for trending ever since, while keeping Icinga
 for monitoring.