[FEATURE] Improved Prometheus metrics

[laurivosandi]

Prometheus Metrics Improvements

Currently, rtl_airband writes Prometheus-style metrics to a file rather than exposing them over an HTTP endpoint. This works with the node_exporter textfile collector, but it introduces several issues:

• Staleness: If the process crashes or hangs, the file remains on disk and Prometheus continues scraping outdated values. A built-in /metrics endpoint would allow Prometheus to immediately detect scrape failures.
• Dependency: File-based metrics require node_exporter, adding an extra dependency for setups that only need rtl_airband metrics.

Metric Naming and Labels

• Metrics lack a standard prefix such as rtlsdr_airband_, increasing the risk of collisions.
• Metric names often omit units; for example, signal level is expressed in dB but the name does not indicate the unit.
• Labels are confusing. Channels are identified with freq="123.450", hiding the fact that the unit is MHz and reducing precision. A clearer approach would be frequency_hz="123450000".
• The optional label key is generic; channel_label would be more descriptive.
• Device identifiers are not consistently included, which complicates filtering and grouping when multiple SDRs are used.

Metric Types

• Signal-related metrics (signal level, noise, squelch, CTCSS) are sampled at high rates but are exported as simple gauges of the latest value.
• Using histograms would better capture the distribution of values over time. I understand this likely has performance penalty, thus histograms could be toggleable via compile/runtime flag
• In Grafana, histograms can be visualized as heatmaps, showing activity patterns, typical signal levels, and bursts of interference — far more informative than just the last sample.

Recommendation

Switch to a standard Prometheus client library (e.g., prometheus-cpp) to:

• Serve a /metrics HTTP endpoint.
• Enforce best practices: metric prefixes, units, counters, gauges, and histograms. https://prometheus.io/docs/practices/naming/
• Remove the need for file-based metrics and reduce staleness issues.