Releases: saxonnicholls/super-log
Release list
super-log 0.4.0
See CHANGELOG.md. Install: sudo apt install ./super-log_0.4.0_.deb (Debian/Ubuntu/Pi) or sudo dnf install ./super-log-0.4.0-1.*.x86_64.rpm (Fedora/RHEL).
super-log 0.3.0 — FIX session logs & MAVLink drone telemetry
Two new capabilities, both verified, on top of proven Linux packaging.
FIX session logs — superlog-fix
Follows QuickFIX / FIX8 message logs (SOH-delimited tag=value) and levels
MsgType so the quiet failures shout: a Reject or a rejected fill is
ERROR with its reason, a Logout or sequence gap is WARN, fills and orders
are INFO, a Heartbeat is DEBUG. The session topic is derived from the message
itself (fix.<begin>-<sender>-<target>), never the filename. Credentials
never reach the bench by construction — a Logon's password (tag 554),
NewPassword (925) and RawData (96) are never read and the raw message is never
emitted. Verified against real QuickFIX logs (~150K messages), where a real
account password in tag 554 appeared in zero events.
Drone telemetry — superlog-mavlink
Binds the MAVLink UDP stream a GCS/SITL forwards (or replays a .tlog) and
decodes v1/v2 frames CRC-checked (CRC-16/MCRF4XX + per-message CRC_EXTRA),
one topic per sysid. Battery and satellites are DEBUG metric readings; a low
battery, a lost 3D GPS fix, an EMERGENCY system status and a link that stops
heart-beating are edge-triggered WARN/ERROR with recovery; mode/arm changes are
one INFO; and the flight controller's own STATUSTEXT rides through at its
MAV_SEVERITY. Verified without a drone — hand-encoded real-CRC frames over a
real UDP socket — including that a bad-CRC frame yields no phantom event.
Packaging — install from the command line
Every artifact below was proven by installing it in a clean container of its
own architecture.
Debian / Ubuntu / Raspberry Pi (64-bit):
# amd64 (x86)
curl -fsSL -O https://github.com/saxonnicholls/super-log/releases/download/v0.3.0/super-log_0.3.0_amd64.deb
sudo apt install -y ./super-log_0.3.0_amd64.deb
# arm64 (64-bit Raspberry Pi, ARM servers)
curl -fsSL -O https://github.com/saxonnicholls/super-log/releases/download/v0.3.0/super-log_0.3.0_arm64.deb
sudo apt install -y ./super-log_0.3.0_arm64.debFedora / RHEL / Rocky / Alma:
sudo dnf install -y https://github.com/saxonnicholls/super-log/releases/download/v0.3.0/super-log-0.3.0-1.fc41.x86_64.rpmOn systemd hosts the hub starts automatically; in a container without systemd,
run superlogd yourself. Then:
echo "the bench is live" | superlog --topic hello
curl -s "http://127.0.0.1:7333/recent?topic=hello"Full notes in CHANGELOG.md.
v0.2.0 — alarms, agents, and OpenTelemetry
The bench that started as one screen for every log stream grew, in this
release, into a bench that watches its own machines, hardware, workers,
money, and the world it depends on — and lets other observability
ecosystems in.
New capabilities since v0.1.0
Alarms & webhooks. Development rules (level / rate / silence / combo)
and a production alarm gateway: a token-guarded public webhook through a
Cloudflare tunnel, deduped by key with repeat counts, heartbeat dead-man,
and a clean channel registry (desktop, webhook, Telegram/Twilio/email).
Webhook testing built in — capture Stripe/GitHub deliveries, verify
signatures on arrival, or relay to your local handler and return its real
response. One-click and manifest-driven endpoint provisioning.
OpenTelemetry inlet. Anything OTel-instrumented joins with no new SDK
— point an exporter at 127.0.0.1:4318. OTLP/JSON and OTLP/protobuf
(a hand-rolled bounded decoder), severityNumber → levels, and the OTel
trace_id becomes the bench's own trace so a single /recent?trace=
returns both worlds.
Six new viewer boards, from one shared menu.json rendered by both
the native and React viewers: servers (who has spoken, how loudly),
devices (USB trees, handsets headlined — is the phone connected?),
agents (which LLM is working the bench, on what cadence), PRs
(waiting-on-us ages to an alarm — born from a real 51-day silence),
webhooks, and the alarm blotter — plus an environment/clock strip.
More producers. C#/.NET, Perl, Lua, Zig, COBOL — and anything with a
C FFI via one object file. SQL gets a voice (Postgres NOTIFY bridge,
SQLite watched from outside). The gas watcher spans EVM, Solana,
Tron and Bitcoin.
The world the bench depends on. Network state (gateway, Wi-Fi, VPN,
resolvers, ARP, ping/traceroute, BGP origin-AS hijack watch) and the
Starlink dish over its own gRPC.
The house rule, kept
Every capability ships a detailed README entry, an MCP guide entry an
agent can query, a PROTOCOL row, and tests driven as subprocesses against
a real hub. The CHANGELOG says what is VERIFIED versus merely written.
134 tests green.
Full detail in CHANGELOG.md.
v0.1.0 — first public release
Changelog
Notable changes, newest first. Each entry says what is verified and what is
not, because that distinction matters more than the feature list.
v0.1.0 — first public release
2026-08-29
One hub for every log stream on a development bench. Nine dependency-free
SDKs, twenty-odd tailers that need no application changes at all, two
viewers, a journal with search and replay, and MCP tools so an agent reads
the same bench you are looking at.
Nought-point-one on purpose. The wire protocol is
settled and documented; the surfaces around it are young and some will move.
What is here
Nine SDKs, no dependencies in any of them. C++ (a spdlog sink and a
native SN_LOG one), Rust with an optional tracing layer, Python plugging
into stdlib logging, Go with a log/slog handler, Java and Kotlin through
java.util.logging, Swift with a @TaskLocal trace, Fortran over raw POSIX
sockets, a POSIX sh producer needing only curl and awk, and one JS
client for Node, the browser and React Native.
Five of them hook the logging framework the language already has, so
everything a program already logs arrives without a call site changing.
Twenty-odd tailers that need no application changes at all. OS logs on
macOS, Linux and Windows; ~20 known services; Docker; any host over ssh; an
HTTP/S logging proxy; WebSocket frames; a syslog and raw TCP/UDP inlet; DNS
records with TLS expiry; listening ports with their processes; host vitals;
builds with their compiler diagnostics; sanitizer and valgrind findings
captured whole; git and GitHub Actions; filesystem changes; serial consoles;
ROS 2; blockchain addresses; GPU telemetry; and tee for anything else that
prints.
Two viewers, a journal with search and replay, GET /recent for scripts,
six MCP tools for agents, and edge-triggered alerts.
Verified on real hardware and services
The hub; both C++ paths; Rust, Python, Go, Java, Swift, Fortran and the shell
producer all delivering live. The JS client in a real Expo app on simulators,
an Android handset, a browser and Node. Both viewers. macOS unified log and
journald. ssh streaming from cloud hosts and a four-server fleet. Ethereum
mainnet. Search and replay over a 1 GB journal. Correlation across tiers.
Sanitizer and valgrind capture against real ASan, TSan, UBSan and valgrind
output. Vivado and Quartus diagnostics. ROS 2 Jazzy. Syslog from real
datagrams. Metal GPU work on an AMD card. A 20-minute Binance soak that found
a real memory problem and confirmed it was not a leak.
CI builds from a clean checkout on Linux under gcc and clang and on macOS
arm64; runs ThreadSanitizer on Linux, where macOS's is broken at the
runtime level; builds the hub with no submodules at all; and runs the
shell producer inside Alpine with busybox ash, busybox awk and no GNU
date.
Written but not verified
Treat these as bring-up, not regression:
- CUDA — no NVIDIA GPU on the machine it was written on
- Windows event logs
- iOS hardware (the simulator is verified)
- Kotlin — no
kotlincavailable - Serial against a real board at a real baud rate (a pty is verified)
- WebGL context loss — needs a browser; the rest of
patchWebGLis tested - gRPC over TLS and against a real client library
Security
No authentication, deliberately. The reasoning, what was rejected and why,
and the questions still open are in docs/DECISIONS.md.
The hub binds loopback; opening it is something you type, and it warns
when it is open. The bar is to be no less safe than the logs a developer
already has, and never more dangerous than them — bound to loopback the OS is
the authentication, and it is the same OS already guarding your log files.
Known wart
SUPER_LOG_PORT means the listen port to the hub and the target port to
a client. Harmless when they coincide, which is usually. Prefer
SUPER_LOG_URL in clients; it is what most of the SDKs read natively and has
no such ambiguity.