Skip to content

Data Sources and Exporters⚓︎

This page lists every source of metrics in a standard deployment: which component produces each metric, which exporter exposes it, and where the upstream documentation for that exporter lives. It also covers how to add a source of your own.

If you are looking for the metrics themselves rather than where they come from, see xCore Metrics, xControl Metrics and Infrastructure Metrics.

Three routes into xView⚓︎

An exporter is a process that presents measurements over HTTP in the Prometheus text format, so a collector can scrape it. At a site — xCore or xRouter, which are monitored identically — metrics reach the collector by one of three routes, and knowing which applies to a component tells you where to look when its metrics go missing.

The Expeto Agent as exporter⚓︎

This is the route most xCore metrics take, and it is the one that surprises people. The 5G network functions and the MME do not serve a metrics endpoint. They report their counters internally over their own management interfaces, and the Expeto Agent collects from each of them every 15 seconds and republishes the whole set as Prometheus metrics on a single endpoint of its own.

The practical consequences:

  • The agent is a single point of collection. If the agent is down, metrics for every network function it fronts stop — the functions themselves may be perfectly healthy. That is what xCoreAgentOutOfContact distinguishes.
  • Every metric collected this way is labelled job="xAgent", whichever network function produced it. The function is identified by nfnode and nfnodeip, not by the job.
  • Resolution is bounded by the poll interval. A counter that moves and moves back inside 15 seconds is not visible centrally.

Components on this route: AMF, SMF, UPF, NRF, NSSF, UDSF, NFCM and the MME.

Native Prometheus endpoints⚓︎

Some components serve their own metrics endpoint, which the site collector scrapes directly. These appear under their own job names, so a failure is attributable to that component alone.

Component Job Path
HSS hss /hss/prometheus
UDM udm /prometheus
UDR udr /prometheus
AUSF ausf /prometheus
Expeto Agent xAgent /metrics
xControl xControl /metrics

Third-party exporters⚓︎

Everything that is not an Expeto component is covered by a standard open-source exporter. These are well-documented upstream, and we do not restate their metrics here — the links below are the reference.

Exporter Covers Job Upstream documentation
node_exporter Host CPU, memory, disk, filesystem and network health for every cluster node node prometheus/node_exporter
kube-state-metrics State of Kubernetes objects: deployments, pods, nodes, PVCs k8s kubernetes/kube-state-metrics
cAdvisor (in the kubelet) Per-container CPU, memory, filesystem and network usage kubelet google/cadvisor
mysqld_exporter Site database health, including Galera cluster state mariadb-galera prometheus/mysqld_exporter
postgres_exporter xControl's database postgres prometheus-community/postgres_exporter
blackbox_exporter Synthetic reachability probes from a site blackbox prometheus/blackbox_exporter

The monitoring stack also exports its own metrics — vmagent, vmalert, the metric database, Alertmanager and Grafana each expose an endpoint, and xView scrapes all of them so that a failure of monitoring is itself visible. Those are documented upstream by VictoriaMetrics, Prometheus Alertmanager and Grafana.

Java runtime metrics⚓︎

xControl and the Expeto Agent are JVM applications. Alongside their application metrics they export standard JVM and process metrics — heap and non-heap memory, thread counts, garbage collection, class loading, file descriptors and process CPU — under the usual jvm_* and process_* names defined by the Prometheus Java client. xControl additionally exports connection-pool, HTTP server and message-broker metrics; see xControl Metrics.

Adding a source of metrics⚓︎

A site's monitoring endpoints are configuration held in xControl, not something compiled into a release. Adding one makes a new exporter's metrics flow through the existing pipeline without any change to xView.

A monitoring endpoint has these fields:

Field Meaning
name Identifies the endpoint. Becomes the xName label on everything it produces.
jobName The job label applied to the scraped metrics.
metricsUrl The HTTP or HTTPS URL to fetch.
scrapedBy Whether the Expeto Agent fetches it, or the site collector does.
scrapeInterval How often to fetch it, in seconds. Also sets how long xControl considers an upload current.
status Whether the endpoint is enabled.

The scrapedBy field selects the route:

  • Agent — the Expeto Agent fetches the URL and relays the response to xControl. This is the route used for the site's own collector, and it is the right choice for anything that must traverse the outbound-only path to xControl.
  • Collector — the site collector scrapes the target directly, as one more target inside the cluster. Use this for an exporter that runs at the site, so its metrics are included in the collector's data and relayed with everything else.

Important

scrapeInterval does double duty for agent-scraped endpoints: it is both the fetch period and the time-to-live attached to the upload at xControl. Setting it much longer than the central scrape interval means xView will periodically find the stored data expired and record a failed scrape. Keep it close to the platform default unless you have a reason not to.

Tip

Prefer pointing a new exporter at the site collector and letting the existing relay carry it centrally, rather than adding a second agent-scraped endpoint. One upload per site keeps the number of central scrapes proportional to the number of sites rather than to the number of exporters.

Metrics from a new endpoint arrive with the site's identity labels attached automatically — see Metric Labels and Conventions. Nothing needs to be configured in xView itself.