xView Guide⚓︎

xView is the monitoring system for the Expeto Platform. It collects metrics from every site in a deployment — xCore and xRouter alike — as well as from xControl and the infrastructure they all run on, stores them centrally, evaluates alerts against them, and presents them as dashboards. The result is one operational view of an estate that may span many sites, customers and networks.

This page introduces xView and points to the reference material. If you are trying to understand how the data reaches xView, start with xView Architecture; if you just want to look at a dashboard, go to Accessing xView.

What xView does⚓︎

• Collects metrics from the network functions, hosts and Kubernetes clusters at every xCore and xRouter site, and from xControl itself.
• Stores them centrally, alongside xControl, with a retention window covering a month of operational history.
• Evaluates alerts continuously, so a developing problem raises a notification rather than waiting to be noticed.
• Presents the result as dashboards covering the whole deployment, a single site, or a single component.

Two properties of the design are worth knowing up front, because they explain most of what you will observe:

Sites are never connected to from outside. A site may sit inside an enterprise network, behind a firewall the platform cannot reach through. So no site is polled: the Expeto Agent at each site pushes its metrics outward to xControl, and xView collects from xControl. Only outbound connectivity is ever required at a site, whether it is an xCore or an xRouter.

Every metric carries the identity of where it came from. Site and customer labels are attached centrally as metrics arrive, so one alert rule covers every site, and any query can be narrowed to a customer or a site without per-site configuration. This is covered in Metric Labels and Conventions.

What xView is built from⚓︎

xView is assembled from established open-source monitoring components, configured and integrated for the platform, with Expeto's own alert rules, dashboards and collection configuration on top:

• VictoriaMetrics stores the metrics and answers queries. It speaks PromQL, so existing Prometheus knowledge, queries and exporters carry over unchanged.
• vmagent scrapes the configured targets; vmalert evaluates the alert rules; Alertmanager routes what fires.
• Grafana provides the dashboards and an interactive query interface.
• node_exporter and kube-state-metrics cover host and Kubernetes health.

The full component list, with upstream documentation links, is in xView Architecture.

Suspending monitoring for planned work⚓︎

Taking a site down for maintenance without suppressing its alerts produces a flood of notifications for a problem you already know about. Mark the Site's state in xControl instead — the platform's alert rules all honor it.

The procedure is in suspending monitoring for a site.

How alerts work⚓︎

Every alert is defined by a PromQL expression evaluated on a schedule, a duration the condition must hold, a severity, and annotations that describe what happened.

An alert becomes pending the moment its expression is true, and firing once it has stayed true for the configured duration. That delay is what prevents a brief spike from paging anyone. It clears automatically when the expression stops being true.

Some alerts escalate. Where a condition matters more the longer it persists, the alert has Tier2 and Tier3 variants that fire after longer durations — a site out of contact for four hours is a different problem from one out of contact for five minutes, and they are distinguishable without anyone having to watch the clock.

Severity is the intended response:

Alerts carry labels identifying the customer, site and component affected, and their annotations quote both the human-readable names and the stable identifiers, so a notification is actionable without having to look anything up.

Where to go next⚓︎