[OPENDJ-5839] Servers should be identified using a single server ID Created: 17/Dec/18  Updated: 07/Nov/19  Resolved: 07/Feb/19

Status: Done
Project: OpenDJ
Component/s: config, replication, tools
Affects Version/s: 6.5.0
Fix Version/s: 7.0.0

Type: Task Priority: Critical
Reporter: Matthew Swift Assignee: Fabio Pistolesi
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
is required by OPENDJ-5904 Doc - OPENDJ-5839: Servers should be ... Done
relates to OPENDJ-5914 Consider removing the configuration o... Done
is related to OPENDJ-5892 entries are not replicated when serve... Done
is related to OPENDJ-5918 Upgrading a server with the server ID... Done
is related to OPENDJ-5928 Setup: typo in error message when ser... Done
OPENDJ-5857 Dev - OPENDJ-5839: Servers should be ... Sub-task Closed Fabio Pistolesi  
OPENDJ-5859 QA - OPENDJ-5839: Servers should be i... Sub-task Closed carole forel  
Epic Link: Replication self-registration
Story Points: 7
Dev Assignee: Fabio Pistolesi
QA Assignee: carole forel


In 6.5 separate server IDs are assigned to each replication domain.

This task can be closed once:

  • servers are only identified by a single server ID (the global server ID)
  • per-domain server IDs are removed
  • 6.5 servers can be upgraded gracefully
  • users can choose a server ID during setup although the tool will provide them with a generated default.

Comment by Fabio Pistolesi [ 21/Dec/18 ]

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.

Comment by Jean-Noël Rouvignac [ 21/Dec/18 ]

Good idea Fabio.

Comment by Matthew Swift [ 21/Dec/18 ]

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?

Comment by Fabio Pistolesi [ 09/Jan/19 ]

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.

Comment by Fabio Pistolesi [ 09/Jan/19 ]

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

Comment by Jean-Noël Rouvignac [ 09/Jan/19 ]

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.

Comment by Ludovic Poitou [ 09/Jan/19 ]

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.

Comment by Jean-Noël Rouvignac [ 09/Jan/19 ]

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.

Generated at Wed Mar 03 02:06:22 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.