Skip to main content

jPOS Log Viewer: structured operational logs

· 4 min read
Alejandro Revilla
jPOS project founder

Most log viewers are built around the assumption that logs are lines of text. Search is grep. Filtering is awk. Correlation is copy-pasting timestamps and hoping for the best. The infrastructure to make that tolerable — log shippers, ingestion pipelines, index clusters — adds cost and complexity, and the result is still a flat text interface.

jPOS' Log Viewer takes a different approach, and it can do so because jPOS's logging is different at the source.

Structured from the start

jPOS has always had a typed, structured event model at its core. Every log event is a self-describing object—not a formatted string, but a record with well-defined fields: timestamp, kind, realm, host, trace identifier, and a typed payload that varies by event type.

This wasn't retrofitted onto the system. It's the foundation. When jPOS 3.0.0 was released, structured audit logging was formalized as a first-class feature—typed events with PCI-aware field protection, flat metadata, and a JSONL serialization that makes log events portable without losing structure.

The Log Viewer indexes these structures directly. That's what makes faceted search, histogram drill-down, and trace correlation possible without any additional transformation layer.

What the demo shows

The video above walks through the viewer from an operator's perspective:

Histogram and time navigation. The event volume histogram at the top is interactive. Clicking a bar zooms into that time window—the date range updates and results narrow to that slice. During incident investigation, this is the fastest way to go from "something happened around 14:30" to "here are all the events in that two-minute window."

Faceted filtering. Column headers act as facet controls. Clicking Kind opens a checkbox dropdown for event types—info, warn, send, receive, deploy, and so on. Clicking Realm narrows to a specific subsystem. Facets compose: combining kind and realm gives an operator exactly the signal they need, without writing queries.

Full-text search with Lucene syntax. The search box accepts field-specific queries: kind:send OR kind:receive, realm:channel, or plain text matched across the payload. Results update immediately.

Multi-event comparison. Selecting multiple rows opens them in a modal with a Plain tab and a JSON tab. The Plain view shows time deltas between events—you can read the exact duration from channel receive through transaction manager processing to response. The JSON tab exposes the raw structured source, ready to copy into an incident report or pipe into another tool.

Trace correlation. Many events carry a trace identifier that spans the entire lifecycle of a request. Clicking the trace link on any row filters to all events sharing that trace—the full journey from channel to transaction manager and back, in one view.

Offline forensic import. The DevTools workspace includes a log ingestor. Drag and drop JSONL log files—from production, from staging, from a colleague's environment—and analyze them with the same faceted search, histogram, and trace tools. Multiple files can be imported together.

Why it works

Generic log aggregation tools treat every system the same way. They expect text, they parse it heuristically, and they provide generic search. That works, but it stops there.

Because jPOS' Log Viewer is built on top of jPOS's typed event model, it can go further. A tag carrying a transaction ID can link directly to data in the general ledger. A deploy event renders with the full list of deployed components, not a raw XML blob. A channel event shows connection state and timing in a purpose-built renderer.

This is the practical difference between indexing structured data and parsing text that was never meant to be parsed.

More to come

The viewer is already useful for operations and debugging. The next steps are deeper integration with jPOS' transaction data — linking log events to their corresponding GL postings, surfacing cost and timing information in context, and making the operational picture and the financial picture visible from the same interface.