xCore Metrics⚓︎

This page is the reference for the metrics an xCore site reports. They are grouped by the network function that produces them, because that is how you will troubleshoot: something is wrong with attach, or with the user plane, or with subscriber data, and you want the counters for that part of the system.

Every metric here carries the site and customer identity labels described in Metric Labels and Conventions, and protocol counters carry the direction, message, type and cause labels specified there. That page is the one to read first — it explains the label pattern this page relies on, and without it the tables below look like far more metrics than they really are.

xRouter reports these same metric families for the network functions it runs, through the same Expeto Agent and under the same job name — so everything here applies to an xRouter site too, for the functions present there.

Mobility management (MME)⚓︎

The MME handles attach, tracking-area update, paging and handover for 4G subscribers.

Protocol counters⚓︎

Supporting counters: xcore_mme_diameter_peer_connection_down and xcore_mme_diameter_timer_expiry (labelled by timer) report Diameter peer health directly, rather than requiring you to infer it from message rates.

Current state⚓︎

These gauges describe what the MME is holding right now, and are the fastest way to size a site or confirm that load has actually moved:

Procedures and failures⚓︎

xcore_mme_procedure_* counts individual procedures — handovers of each kind, operator-initiated resets, bearer modifications, dropped packets — and xcore_mme_failure_* counts the corresponding failure cases. They are the detail behind a raised failure rate seen in the NAS or S1AP counters.

SMS and circuit-switched fallback over SGs have their own counters: xcore_mme_sgh_mo_sms_received_total, xcore_mme_sgh_mt_sms_received_total, the matching _dropped_ variants, and xcore_mme_sgh_combined_attach_total with xcore_mme_sgh_successful_combined_attach_total.

Emergency and closed-subscriber-group handling: xcore_mme_emergency_call_total, xcore_mme_emergency_sessions_with_imei_total, xcore_mme_emergency_sessions_witout_auth_total, xcore_mme_csg_calls_with_subscription_expired_total and xcore_mme_csg_calls_failed_for_subscription_not_available_total.

Session management (SMF)⚓︎

The SMF establishes and maintains sessions, and controls the user plane over PFCP.

Protocol counters⚓︎

Sessions and associations⚓︎

Session counts are the first thing to check against the configured capacity of a site: a session count that has flattened at a round number is a limit, not a traffic pattern.

Identifier and address allocation⚓︎

xcore_smf_idallocated and xcore_smf_idavailable, with xcore_smf_ipallocated and xcore_smf_ipavailable, report the allocators that hand out session identifiers and UE addresses. xcore_smf_idallocator_queue reports pending allocation requests; a queue that is not draining means sessions will start failing shortly, which makes it a useful leading indicator. xcore_smf_idallocator_total and xcore_smf_ipallocator_total count allocation operations.

User plane (UPF)⚓︎

The UPF forwards subscriber traffic and enforces the rules the SMF installs.

Throughput and volume⚓︎

Sessions and PFCP⚓︎

xcore_upf_active_pfcp_sessions and xcore_upf_active_pfcp_association report what the UPF is currently holding. Comparing the session count against the SMF's own view is the standard way to detect a user plane that has drifted out of step with the control plane.

PFCP procedures are counted per procedure and outcome — for association setup, and for session create, modification, release and report, each with _total, _success and _failed:

rate(xcore_upf_pfcp_session_create_failed[5m])

On an xCore installed with the operator, every user plane reports its own series: the Agent reads each UPF's statistics from NFCM and labels them with the UPF's nfnode (elm-nfcm-statistics-<user plane>) and with upf, role (sgwu, pgwu, upf, iupf), position (front or anchor), mode and, for an anchor, systemid. Three further series describe each user plane and join on nfnode: xcore_upf_info (value 1, with the labels above plus dnn, n9peers, serviceid, tenantid and site), xcore_upf_dataplanes (its dataplane pods) and xcore_upf_sessions_per_dataplane (the session table of each). Sessions held by the anchors of one System, for example:

sum by (systemid) (xcore_upf_active_pfcp_sessions{position="anchor"})

Path health is reported by xcore_upf_pfcp_peer_down, xcore_upf_pfcp_msg_retrans_timer_expiry, xcore_upf_echo_req_recv, xcore_upf_echo_resp_send, xcore_upf_gtp_error_ind_recv and xcore_upf_gtp_error_ind_send. A rising error-indication count usually means the peer has lost session state that this node still believes exists.

Access and mobility (AMF)⚓︎

The AMF handles registration, connection management and paging for 5G subscribers. Its counters name the procedure and outcome in the metric itself, so they are read directly rather than aggregated by label.

The families follow a predictable shape — xcore_amf_registration_initial_* for initial registration (accept, complete, identity request and response, authentication request and response, and the reject reasons), xcore_amf_registration_periodic_* and xcore_amf_registration_mobility_* for the other registration types, xcore_amf_dereg_* for deregistration, xcore_amf_paging_* for paging, and xcore_amf_nas_connection_established / xcore_amf_nas_connection_terminated for connection state.

Interactions with other network functions are counted per peer and outcome under xcore_amf_*_consumer_stats and the xcore_amf_nas_transport_* families, covering the AUSF, UDM, SMF, NSSF, NRF and UDSF.

Subscriber data (HSS)⚓︎

The HSS authenticates subscribers and serves their subscription data. Every interface it implements reports through one family, xcore_hss_<interface>_messages_total, labelled by message, type and cause:

Because the shape is identical, one query covers any of them:

sum by (site, cause) (
  rate(xcore_hss_s6_messages_total{message="authentication_information", type="response"}[5m])
)

Signalling link state is reported by xcore_hss_link_total — labelled by type (diameter, map, smpp) and status — against xcore_hss_link_count, the number of links expected to be open. A gap between the two is what the connection-down alerts detect. xcore_hss_link_dropped_messages_total counts messages lost on a link.

xcore_hss_3g, xcore_hss_4g, xcore_hss_active and xcore_hss_vlr report subscriber and register counts, and xcore_hss_msrn_get_total counts roaming-number allocations. The xcore_hss_diameter_sum, xcore_hss_map_sum and xcore_hss_sip_sum families carry latency aggregates per protocol.

Supporting functions⚓︎

The network repository, configuration manager and unstructured data store report their API calls per operation and outcome:

• xcore_nrf_nf_* — network function registration, update, deregistration and discovery, on an xRouter; an xCore runs without a network repository
• xcore_nfcm_*_api_* — configuration management operations, per resource
• xcore_udsf_udsf_req_* — record store requests

Each family follows the _total / _success / _failed pattern.

Platform and site-wide metrics⚓︎

These describe the site as a whole rather than a single network function, and most of the default alerts are built on them.

Provisioning synchronization⚓︎

The agent continuously reconciles what xControl says a site should hold against what the site actually holds, and reports the difference:

All five are labelled by component, so they cover subscribers, keysets and radios separately. Non-zero mismatch, missing or extra counts drive the synchronization alerts in xCore Alerts.

Charging records⚓︎

xcore_cdr_count and xcore_cdr_buffer report charging records produced and records waiting to be written. A buffer that grows steadily means records are being produced faster than they are being delivered, and will eventually be lost.

Agent internals⚓︎

The agent's own health: xcore_queue_status, xcore_jms_event_time and xcore_jms_delay_time with their _count companions, xcore_threadpool_fast, xcore_threadpool_slow and xcore_threadpool_dedicated with theirs, xcore_unhandledevents_total, and the REST response counters xcore_rest_2xx_responses_total, xcore_rest_3xx_responses_total, xcore_rest_401_UNAUTHORIZED_responses_total, xcore_rest_404_NOT_FOUND_responses_total and xcore_rest_5xx_responses_total.

Growing JMS delay is the signal that the agent is falling behind xControl, which is what AgentJmsMessagesDelayed detects.

SMS centre⚓︎

xcore_smsc_stored_sms_total, xcore_smsc_mo_forward_ok_total and xcore_smsc_map_sent_ok_total count stored and forwarded messages.

Related pages⚓︎

• Metric Labels and Conventions — the label pattern these metrics follow
• xCore Alerts — the default alerts built on these metrics
• xControl Metrics — the central platform's own metrics
• Infrastructure Metrics — hosts, containers and Kubernetes