Enforce metric name rules

[poulok]

There are currently no restrictions on what characters can be used in metric names. Some characters cause problems for systems like Prometheus and Elastic to ingest. There are currently scripts that modify metric names to make them compatible with other systems.

Metric names should be validated at the time of creation. There are at least two options for this:

1. Throw an exception when a metric is created with an invalid name
2. Modify the name of the metric to conform to the standards when publishing to externals

Elastic converter: https://github.com/swirlds/infrastructure/blob/master/hedera-utils/PipelineGenerator.py Prometheus converter: com.swirlds.common.metrics.platform.prometheus.NameConverter

[mxtartaglia-sl]

Noting here to discuss with @tannerjfco:

1. Elastic Converter: it is not there anymore; where should I look for it? What are the constraints for the converter?
2. A suggestion is to throw an exception during Metric creation, but should that be accompanied by some change other than the hedera-services codebase?
3. How can I get Prometheus access?

[poulok]

We decided to log an error if a metric violates a rule, and not throw an exception. The log message will fail nightly tests but not cause problems in a production network.

Additionally, check the unit name for compatibility because the unit is appended to the metric name.

[mxtartaglia-sl]

List of decisions made after discussing with @hendrikebbers	Option 1	Option 2
	Throw exception	Log Error
Design		✓
	Not Required	Required for Metrics Supporting Units
Unit	✓
	suffix of the name	Prometheus handle
Unit		✓
	Fixed values	Free values
Unit		✓
	Create and assert naming conventions	Free values
Naming Style		✓
	Validate In Metrics Framework	Validate in Prometheus adapter
Design		✓
	Extension	Performance
Design		✓

• We should perform the validations as close to the Prometheus client as possible, given that we want to maintain independence between the framework and the tool used to report.
• metric units will not be mandatory.
  1. Making them mandatory introduces some challenges, such as having to replicate some logic Prometheus implements to identify the type of metrics that cannot have a unit;
  2. Unit field might not be enough context for all the public consuming the metric; some would need a description to understand what the metric is measuring, and we cannot make all fields mandatory. What we need is a way to make Graphana, Prometheus, and our framework share metadata that can better describe the information the metric is representing.
  3. Having the metrics receiving a fixed unit value would create a coupling point and the need to have a process in place to create new units in case of necessity.