Oninit® Logwalker — For Architects
Observability for a relational database has two distinct shapes: "what is the engine doing now" (covered by onstat, by Grafana dashboards, by CDC streams to a downstream lake) and "what did the engine do in this particular transaction window" (covered historically by onlog -l plus folklore). The first shape is well-served on Informix. The second is where Logwalker lives.
Logwalker is a focused, single-purpose log reader that turns a known-position window of the Informix logical log into a faithful, typed, partnum-resolved text stream. The output is shell-pipeline friendly — one line per record, stable column order — so it slots into whatever downstream observability stack you already have, without dragging in an SDK or a new agent.
Where it fits in the stack
| Layer | Logwalker's role |
|---|---|
| Engine | None. Logwalker is a CSDK-side client; the engine sees one CONNECT to sysmaster and nothing else. The engine doesn't need a hook, a UDR, an XBSA module, or any other server-side machinery. |
| Operating system | Reads raw chunk files via O_RDONLY + pread(). Same I/O pattern onlog -l uses, same permissions story. Lives in normal user space, not in the engine's address space. |
| CDC / replication | Parallel to it. Logwalker reuses Oninit® Log Ripper's raw-log reader (liboni_logripper.so); the byte-level interpretation is identical to what a live capture would produce. Use the Ripper for streaming, Logwalker for the one-shot point-in-time view. |
| SIEM / observability pipeline | Output is plain text, line-per-record. Pipe to your log shipper; use the --compat onlog form if your shipper already has an onlog parser, or the HUMAN form if you'd rather index typed fields. |
Integration story
- No new protocol. Output is text; integration is fork() + read(). No client library to vendor; no network port to firewall.
- No persistent state. Each invocation is one walk. There's no journal to back up, no offset file to coordinate across restarts, no shared lock with the engine.
- Reuses Ripper code. The byte-level reader is the same primitive the live CDC tool uses. Coverage extensions land once and benefit both.
- Drop-in onlog. Existing log-analysis tooling that already targets onlog -l's shape continues to work unmodified under --compat onlog.
Risk surface
| Concern | How Logwalker handles it |
|---|---|
| Production data exposure | The tool reads what's already on the operator's permitted chunk files; it adds no new access path. The deployment constraint is intentionally hard: the operator must already have R_OK on every chunk in the extent map, or the walk doesn't start. |
| Inadvertent write | Architecturally impossible. The walker uses O_RDONLY and pread(); the sysmaster session issues no BEGIN WORK. There is no write code path. |
| Engine impact | One sysmaster connection, two short SELECTs (phase 1 and phase 2 catalogs), then disconnect. The raw-chunk reads bypass the engine entirely — they're OS file I/O. The engine sees no logical workload during the walk itself. |
| Cross-version drift | The body decoders are empirically derived per IDS version and re-checked when a regression surfaces. The maintenance contract is explicit and documented; the Troubleshooting page lists every diagnostic shape and what version-shaped issue it indicates. |
Deployment shape
A single binary, compiled against the local CSDK. No daemon, no listener, no shared state across invocations. The natural deployment is to drop the binary in the operator-tools directory on every host that owns a log dbspace, then invoke it from runbooks or incident playbooks. No package manager required; no orchestrator to configure; no rolling restart of the engine to install or upgrade.
Backed by Oninit, the team known across the Informix community as "the Down System Specialists". Architecture conversations at support@oninit.com or +1 913 732 8892 (US) / +44 20 8133 7529 (UK).