Stable naming for input, output, processor and other internal gNMIc metrics

[pobk]

I’d like to propose standardising the structure and naming of gNMIc internal metrics across inputs, processors, outputs, targets, and plugins.

At the moment, internal metrics appear to follow slightly different naming and labelling patterns depending on the component. This makes dashboards and alerting rules harder to reuse and increases the cognitive load when working across different parts of the system.

Proposal

1. Consistent Metric Naming

Adopt a predictable naming scheme based on component and metric type:

gnmic_<component>_<metric>_<suffix>

Where:
<component>: input | processor | output | target | plugin | loader
<metric>: msgs | bytes | success | failures | duration
<suffix>: total | count | seconds | up (following Prometheus conventions)

Examples:

gnmic_output_msgs_total
gnmic_output_failures_total
gnmic_output_bytes_total
gnmic_output_duration_seconds

This keeps metric names short and avoids repetition of implementation type within the metric name.

2. Standardised Labels

Expose a consistent label set across components:
type - implementation type (e.g. nats-jetstream, kafka, prometheus-write)
name - configured instance name
worker - optional worker identifier (when applicable)

Example:

gnmic_output_msgs_total{
  type="nats-jetstream",
  name="jetstream",
  worker="0"
}

This keeps identity dimensions separate rather than encoding them into a single label value.

3. Thin Wrapper Over Prometheus

To avoid duplication and drift between components, this could be implemented via a small shared helper around native Prometheus types e.g. CounterVec, GuageVec and HistogramVec.

The goal would not be to abstract Prometheus away, but simply to:

• Centralise metric naming conventions
• Enforce the standard label set
• Reduce duplicated metric registration logic
• Make new inputs/processors/outputs automatically consistent

Each component would still use normal Prometheus primitives under the hood.

If this direction makes sense, I’d be happy to draft a PR that introduces the shared helper and migrates one component as a proof of concept before broader changes.