Logs & Subscriber Tracing

OmniWeb gives operators several complementary, real-time views into what the network is doing:

1. Logs — structured, live service logs for any single element, powered by Loki.
2. Session Trace — a cross-network view that follows one subscriber across every protocol and element (Diameter, GTP-C, PFCP, SIP, MAP).
3. Homer — deep SIP/VoIP packet capture and call-flow analysis.

← Back to Operations Guide

---

Real-Time Logs (Loki)

Every element has a Logs tab. It queries the element's service logs from Loki and streams new lines as they arrive, so you can watch an element live while you make a change or reproduce an issue.

The Logs tab (here on a UPF) — structured, colour-coded log lines streamed from Loki, with service, severity, protocol, and subscriber (IMSI) filters. Every element exposes the same viewer.

How log queries work

The frontend builds a LogQL query and sends it through the backend's Loki gateway. Nothing queries Loki directly from the browser — it is proxied (and therefore authenticated and audited) like every other request.

The backend's Loki target is set by the LOKI_URL environment variable (default http://localhost:3100). Queries use Loki's range-query API with a LogQL expression, a time window, a result limit, and a direction (newest-first or oldest-first).

Selectors vs. pipeline filters

OmniWeb builds structured queries from two kinds of filter:

Filter placement	LogQL position	Example	Use
Selector	Inside the stream selector { … }	{hostname="opt-dev-upf01"}	Pick which streams (which host/service) to read. Indexed and fast.
Pipeline	After a |	| level="error"	Filter the matched lines by a structured field.

A typical element Logs tab pins the host/service as a selector and lets you add pipeline filters (severity, component, subscriber identifiers) on top. Because Omnitouch services emit structured log lines, you can filter on real fields rather than grepping free text.

Structured logging data

Hosts ship structured logs to Loki (configured by the Ansible common role). Two especially useful structured sources:

• Service logs — each NF's own structured output, labelled by hostname/service, available on that element's Logs tab.
• Command audit — every command executed on a host, including who logged in (surviving sudo/su), the effective UID, the binary, the working directory, and the full command line. Shipped to Loki. See Audit Logging for the field reference.

Using the Logs tab

1. Open any element and select Logs.
2. The viewer loads recent lines for that element and begins polling for new ones.
3. Narrow the view with pipeline filters (e.g. severity, or an IMSI/MSISDN if the service logs include it).
4. Adjust the time window to look back at a past event.
5. Pause polling (header indicator) to hold a stable view while reading.

Tip: When investigating one subscriber, filtering element logs by their IMSI/MSISDN is the fast first step; to see the subscriber across multiple elements at once, use Session Trace below.

---

Session Trace — Follow a Subscriber Across the Network

The Session Trace engine correlates signalling for a single subscriber across multiple elements and protocols, giving one unified timeline from radio attach through authentication, session establishment, and call/SMS delivery. This is the tool for answering "what happened to this subscriber?" without hopping between element CLIs.

Session Trace — search by IMSI or MSISDN and correlate a subscriber's activity across Diameter, GTP-C, PFCP, SIP, and MAP, with per-protocol tabs across the top.

Supported protocols

Protocol	What it shows	Elements involved
Diameter	Authentication, policy, charging	HSS, DRA, PGW-C, PCRF, OCS, CSCF (Cx/Dx/Rx)
GTP-C	Session management (S5/S8, S11)	SGW-C, PGW-C, MME
PFCP	User-plane session rules (N4)	PGW-C/SMF ↔ UPF
SIP	IMS call control	P-CSCF, I-CSCF, S-CSCF, TAS
MAP	SS7 location, authentication, SMS	MSC, HLR, CAMEL GW, IP-SM-GW

User Trace

The User Trace view lets you search by IMSI or MSISDN and see every correlated protocol interaction for that subscriber across the network. A single attach, for example, surfaces the Diameter authentication, the GTP-C session creation, and the PFCP rule installation as one coherent sequence:

Protocol-specific tabs

Each protocol has its own tab — Diameter, GTP-C, PFCP, SIP, MAP — plus an All Protocols overview. The per-protocol tabs are filtered views, useful when you are chasing a protocol-specific problem (e.g. only the SIP exchange of a VoLTE call) rather than following a single subscriber across everything.

Upload PCAP

The Upload PCAP tab accepts packet-capture files for offline analysis. Uploaded captures are parsed and indexed and then appear through the same trace interface as live data — useful for analysing captures taken from network taps or element-level traces. The backend tracks each upload as a job you can revisit.

---

Homer — SIP Capture & Call-Flow Analysis

OmniWeb integrates with Homer, the open-source SIP capture and VoIP troubleshooting platform, for deep call-flow visualisation, protocol decoding, and search across captured SIP signalling. Where Session Trace gives a cross-protocol summary for one subscriber, Homer gives the full, message-by-message SIP packet detail.

Availability & access

Homer is optional and auto-detected. On startup OmniWeb checks /api/homer/status:

• If Homer is configured (HOMER_URL set on the backend) and reachable, a Homer entry appears in the sidebar.
• If Homer is not deployed, the entry is simply hidden — nothing else changes.

Clicking Homer opens the Homer web UI in a new browser tab. Authentication is transparent: the gateway verifies your OmniWeb login via the same single sign-on used for Grafana, so there is no second login. The backend's HOMER_URL (and HOMER_PROXY_SECRET, when set) configure the integration.

Use cases

Homer is the tool to reach for when a problem is in the SIP layer itself:

• VoLTE call-flow analysis — trace SIP INVITE/BYE sequences through P-CSCF, I-CSCF, S-CSCF, and TAS.
• VoWiFi troubleshooting — analyse ePDG ↔ P-CSCF SIP interactions.
• IMS registration debugging — inspect REGISTER / 401 / REGISTER / 200 OK exchanges.
• Interconnect issues — capture SIP-trunk signalling between the MSC and SIP peers.

Session Trace vs. Homer

Both help with troubleshooting, but they answer different questions — they are complementary, not alternatives:

Tool	Best for	Scope	Where it opens
Session Trace	"Follow this subscriber across the whole network"	Diameter, GTP-C, PFCP, SIP, MAP correlated by IMSI/MSISDN	Inline in OmniWeb
Homer	"Show me the exact SIP messages for this call"	SIP/VoIP signalling, full packet decode (VoLTE/VoWiFi/IMS)	New tab (auto-detected)

A common flow is to spot a SIP-related anomaly in Session Trace, then jump to Homer for the detailed call flow.

---

Troubleshooting

No logs appear on an element's Logs tab

Symptoms: The Logs tab is empty or shows "no results".

Possible causes:

• Loki is not reachable from the backend (LOKI_URL misconfigured).
• The host is not shipping logs to Loki (log shipping not running / misconfigured).
• The selected time window predates the available logs, or the host label does not match.

Resolution:

1. Confirm LOKI_URL points to a reachable Loki instance.
2. Verify the element's host is shipping logs (check the log-shipping agent on that host).
3. Widen the time window and remove pipeline filters to confirm any lines arrive.

Session Trace returns nothing for a subscriber

Symptoms: A User Trace by IMSI/MSISDN shows no events.

Possible causes:

• The subscriber was inactive in the selected window.
• The identifier is mistyped (IMSI vs. MSISDN).
• Trace sources for the relevant protocol are not feeding the engine.

Resolution:

1. Re-check the identifier and try the alternate one (IMSI ↔ MSISDN).
2. Widen the time window.
3. Confirm with the element's own Logs tab that the subscriber was active at all.

The Homer entry is missing from the sidebar

Symptoms: No Homer link appears.

Possible causes:

• Homer is not deployed, or HOMER_URL is not set on the backend.
• Homer is unreachable, so /api/homer/status reports it as unavailable.

Resolution:

1. Confirm Homer is deployed and HOMER_URL is set on the OmniWeb backend.
2. Verify the backend can reach Homer, then reload OmniWeb (detection runs at startup).