I was wondering, would it be useful to generate a serverid even for proxies for identification purposes? Proxy would not use it, but it could be exposed in cn=monitor as well.

Good idea Fabio.

All servers should have a server ID. The attribute should be mandatory.

Jean-Noël Rouvignac - can we use the server ID for naming Prometheus metrics?

Collateral effect of making the attribute mandatory is that adding a 7+ server in a <7.0 topology will not work anymore using dsreplication as the config from <7.0 will not match the definition anymore.

This is the first change requiring full topology upgrade before adding a new server.

Matthew Swift I will try to answer your question.

In Prometheus view, the server ID should only be a dimension, nothing more.
Said otherwise we do not want the name of metric to include the server ID. Metric names should be "stable" coordinates. Example of metric names: https://backstage.forgerock.com/docs/ds/6.5/reference/#monitoring-metrics-prometheus
We already use the server ID as a dimension for many metrics.
Do we want to expand it to all metrics?

Today, I think prometheus adds a {{job}} and {{instance}} dimension to all the metrics from a single scrape target.
The value for {{job}} is provided by the configuration of the scrape targets, either static or via a service discovery mechanism.
Typically, if operators hate self inflicted pain, they would make sure to setup {{job}} to be the same as the global server ID.

Based on the recent Prometheus presentation at the AlpesJUG, I think that {{job}} is intended to represent a class of service, and {{instance}} the name of one of the servers of that class. In other words, I think it's more likely that the {{instance}} be the same as the global server ID, whereas {{job}} would be "ForgeRock DS" or "Tomcat" or the likes.

Argh I remember you told me that the other day.

You are right about the {{job}} unfortunately, {{instance}} cannot be used to put the server id in because it is a <host>:<port>. See https://prometheus.io/docs/concepts/jobs_instances.
So it looks like we may need to do something more about the server id with regards to monitoring with Prometheus.