Adding Routing Intelligence To Your Observability Stack

Observability has a blind spot, and for most teams it sits at the network layer. You instrument your services, scrape metrics into Prometheus, ship logs somewhere searchable, and build dashboards that tell you when something is wrong inside your infrastructure. But the routing that carries traffic to and from that infrastructure often lives entirely outside the stack, watched through separate tools that do not talk to your alerting. This piece looks at why routing belongs in your observability pipeline and what it takes to get it there.

The gap between "up" and "reachable"

Your monitoring can show every service healthy while users cannot reach you. The reason is that reachability depends on Border Gateway Protocol, the system that decides how networks route traffic to each other, and BGP state is not something your application metrics capture. A prefix can be hijacked, a route can leak, or an origin can change, and your internal dashboards stay green because the problem is one layer down from anything they measure.

Teams usually discover this gap the hard way. An incident starts, the service metrics look fine, and someone eventually thinks to check routing, only to find the answer scattered across a looking glass, an RPKI validator, and a WHOIS lookup that none of the on-call tooling knows about. The data exists. It just is not part of the observability surface the team actually watches.

What routing observability needs

Bringing routing into the stack is not about collecting more of the same. It requires a few specific things that general-purpose monitoring does not provide on its own.

1. Live state, not snapshots. Polling a route collector every few minutes misses transitions. You want changes as they happen, which is what the BGP Monitoring Protocol provides by streaming routing tables from routers as they update.
2. Context attached to each event. A raw route change is not actionable until you know whether the origin is authorized, who owns the prefix, and whether this is normal. That context has to arrive with the event, not be looked up manually afterward.
3. Native Prometheus metrics endpoint. For routing to live in your stack, it has to expose the signals you care about in a form your existing tooling already understands, which in most shops means Prometheus.

Meet those three requirements and routing stops being a separate manual investigation and becomes just another instrumented layer, with alerts that fire on the conditions you define.

Wiring it in

This is the role Netomics routing platform is designed to play. FastNetMon built it as a self-hosted routing intelligence platform that ingests live BGP Monitoring Protocol feeds and joins them with historical routing state, ASN and prefix ownership, RIR and WHOIS data, IRR records, geofeed information, RPKI validation and ASPA status into a single routing intelligence solution.

For an ops team, the integration points are the interesting part. The platform exposes routing intelligence through REST APIs, bulk lookup interfaces, and Prometheus metrics, so routing intelligence can be integrated into existing Prometheus-based monitoring and alerting workflows. Because it runs inside your own infrastructure, there are no external rate limits throttling those scrapes and no routing data leaving your network. It was introduced in the launch announcement recently.

FastNetMon founder Pavel Odintsov described the intent behind it: "Internet routing has become critical operational infrastructure, yet many organisations still depend on multiple external services to understand what is happening in their own networks. We built Netomics to give operators complete ownership of their routing intelligence while making it easier to troubleshoot incidents, automate workflows and improve routing security."

There is also a forward-looking angle for teams building automated operations. The platform includes native Model Context Protocol (MCP) support, which lets AI assistants query live routing data directly. That opens the door to automated triage, where an anomaly detected in your metrics kicks off an investigation that pulls the prefix, its history, and its validation status before a human is even paged.

What you can actually alert on

The value of routing observability becomes obvious once you look at the conditions worth alerting on, most of which are invisible to service-level monitoring. Consider a few that map cleanly onto metrics.

An unexpected origin change means a prefix you care about is suddenly being announced by a different AS than usual, which is the signature of both hijacks and misconfigurations. A multi-origin event, where two autonomous systems announce the same prefix at once, is often the first observable sign of a conflict. An RPKI-invalid announcement for your own address space tells you someone is originating a route that contradicts your published authorizations. And a sustained increase in the number of more-specific prefixes covering your space can indicate a leak in progress.

None of these show up in application metrics, because none of them are application problems. They are routing problems, and they are exactly the kind of condition that a NOC wants to catch early rather than discover through a flood of user reports. Expose them as metrics and they become ordinary alert rules, indistinguishable in your workflow from a CPU threshold or an error-rate spike.

A practical rollout

If you want to add routing to your observability, the sequence is straightforward. Start by getting live routing state into the platform via BMP from your border routers. Then decide which routing conditions deserve alerts, the same way you would for any other subsystem, and expose those as Prometheus metrics your existing rules can act on. Finally, connect the routing dashboards to the same place your team already looks during an incident, so nobody has to remember that routing lives somewhere else.

The payoff is that the next time services look healthy but users cannot reach you, routing is not a separate investigation anyone has to remember to launch. It is on the same board as everything else, alerting on the same pipeline, telling you what changed and whether it was authorized. Closing the gap between "up" and "reachable" is mostly a matter of treating routing as a first-class part of the stack instead of an afterthought that lives in someone else's tool.