Documentation menu
Observability & analysis
Metrics, streaming telemetry, offline config analysis and packets
Everything on this page is read-only. That is deliberate: it is the half of the platform you can point an agent at without an approval gate, and it is where most incidents get diagnosed. Changing anything still goes through the ticket lifecycle.
Where this lives in the product
There is no separate observability console: telemetry is queried where the question is asked. Operators read it inline on the dashboard, on alert records and on device pages, while the agent reaches the same backends through MCP tools. The single configuration surface is Settings → Observability, which holds the connection details for the telemetry sources these tools read from.
PromQL queries, gNMI get/subscribe, Batfish analysis and packet inspection cannot change a device. That is why an agent may run them without an approval gate — and why they are the first thing to reach for when you want an answer rather than an action.
Prometheus and Grafana
Prometheus is queried over the API rather than by logging into the host. The agent gets the same query surface a human does, which is what lets it say "this has been climbing for twenty minutes" with evidence instead of speculation.
| Capability | Use it for |
|---|---|
| Instant query | A single value right now — is it still broken? |
| Range query | A trend over time — when did it start, is it recovering? |
| Metric discovery | Finding the metric name rather than guessing it |
| Metric metadata | Understanding units and type before trusting a number |
| Target health | Telling a flat metric from a stopped scrape |
| Server health | Confirming Prometheus itself is up and scraping |
A metric that stopped being scraped and a metric that is genuinely stable look identical on a graph. Querying target health first is the difference between a correct diagnosis and a confident wrong one.
Streaming telemetry: gNMI and NETCONF
For platforms that support model-driven telemetry, gNMI gives capabilities discovery, path-level get and set, and subscribe for a stream. NETCONF is available alongside it for configuration-oriented platforms.
- Capabilities — what the device actually supports, before asking for a path it does not have.
- Get — retrieve a specific path.
- Set — change a path. This is mutating and therefore approval-gated.
- Subscribe — stream updates instead of polling.
Platforms covered include IOS-XR, Juniper, Arista and Nokia. Not every platform supports every verb, which is exactly why capabilities discovery is the first tool rather than an afterthought.
Batfish: offline configuration analysis
Batfish parses configurations without touching the devices, which makes it the right tool for questions you cannot answer safely on a live network — will this change break reachability, and what is different between two snapshots.
- Reachability analysis between two points, given the current configuration.
- Snapshot comparison — what changed between then and now, and what that implies.
- Routing verification — is the control plane actually producing the paths you expect?
- Pre-change validation, before an approval rather than after an outage.
Because Batfish reasons over a copy, asking it a question is never a change. Use it during planning — particularly "what would happen if" — and keep live devices for commands that need live state.
Packet Buddy
Packet captures are where reasoning ends and evidence begins. Packet Buddy analyses a capture with tshark and returns the parts that answer a question, instead of a wall of per-packet output.
| Analysis | Answers |
|---|---|
| Protocol hierarchy | What is actually in this capture, by volume |
| Conversation streams | Which two endpoints are talking, and how much |
| Filtered extraction | The specific flows behind a symptom |
# A capture answering "why is this session slow?"
# 1. What is in here at all
packet_buddy {"path": "/captures/edge.pcap", "mode": "protocol-hierarchy"}
# 2. The flows that matter
packet_buddy {"path": "/captures/edge.pcap", "mode": "streams"}
# 3. Narrow to the suspect conversation
packet_buddy {"path": "/captures/edge.pcap", "mode": "filter",
"filter": "tcp.port == 443 && ip.addr == 10.20.30.40"}Packet Buddy reads captures rather than triggering them. Start the capture on the device you already trust for that job, then hand the file to OrcaMonitor so the analysis is repeatable and shareable on the ticket.
Flow and discovery tooling
- Flow analysis — who is talking to whom, to complement the point-in-time view a capture gives.
- Topology discovery — building the neighbour graph that correlation uses to attach symptoms to causes.
- Network scanning — CIDR-restricted, port-restricted and audited, which is why it is a tool and not a shell command.
Scan and path-trace tools enforce a /24 CIDR allow-list, a port allow-list and audit logging. Running nmap from a local shell bypasses all three, which is why it is not installed in the agent's workspace.
OrcaMonitor documentation v1.0.0 · Report a problem
See every module, pricing tier, and deployment option on the OrcaMonitor overview.