metrics_patterns

Current Prometheus Metrics Setup

Structure

• Central metrics files:

  • metrics/gateway.go - Gateway-level metrics (requests, duration, response size)

  • metrics/server.go - Prometheus metrics server setup

  • metrics/prometheus_reporter.go - Metrics reporter interface

  • cmd/metrics.go - Metrics server initialization

• Protocol-specific metrics:

  • metrics/protocol/shannon/metrics.go - Shannon protocol metrics

• QoS-specific metrics:

  • metrics/qos/evm/metrics.go - EVM QoS metrics

  • metrics/qos/solana/metrics.go - Solana QoS metrics

Pattern Analysis

Common Constants

• All metrics files use pathProcess = "path" as the subsystem name.

• Each file defines specific metric name constants (e.g., requestsTotal, relaysTotalMetric).

Registration Pattern

• Each metrics file has an init() function that calls prometheus.MustRegister() for its metrics.

• Metrics are defined as package-level variables using prometheus.NewCounterVec, prometheus.NewHistogramVec, etc.

Metric Definition Structure

example_metric_definition.go

var myMetric = prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Subsystem: pathProcess,  // Always "path"
        Name:      metricName,   // Defined as constant
        Help:      "Description...",
    },
    []string{"label1", "label2"},  // Labels
)

Publishing Pattern

• Each metrics file exposes a PublishMetrics() function.

• Uses prometheus.Labels{} to set label values.

• Calls .With(labels).Inc() or .With(labels).Observe(value) on metrics.

Version Handling

• Project uses git-based versioning via: git describe --tags --always --dirty

• No existing version metric is present in the current setup.

• Build process injects values via ldflags in makefiles/release.mk.

Notes for implementers:

• Consider adding a global version metric (e.g., a gauge with the build/git description) if you need rollout/telemetry correlation.

• Keep subsystem consistent (path) as in existing files to maintain metric grouping.