saxonnicholls/super-log

**One hub for every log stream you have — devices, servers, containers,
browsers, chains and apps.**
This project is a consolidation of a patchwork of tools I have used, in
one form or another, over the last fifteen years — the log mergers, port
watchers, build wrappers, ad-hoc proxies and one-off scripts every
long-running bench accumulates — rebuilt here as one coherent thing, on
one wire protocol, with one screen.
Free and self-hosted, forever. It **collects and consolidates**; analysis
is a separate, cleaner concern — hand the consolidated stream to
super-log.com for real-time LLM analysis and team
features, or to your own store. See
Collection is not analysis.
*Twelve producers on one screen, interleaved by arrival: C++ through both
SN_LOG and spdlog, Rust, Go, Python, Swift, Fortran, a POSIX shell script,
two React Native devices, Metal GPU work reporting real bandwidth, and a
live Binance WebSocket. The last of those is running at hundreds of frames a
second — so it is rate-capped, and says so rather than silently dropping
them.*
If you build across devices, you know the ritual: a Metro console for the
iOS simulator, another for the Android emulator, adb logcat for the phone
on your desk, a terminal for the C++ engine, another for the Rust service,
browser devtools for the web build, and an ssh session to the box in the
cloud. Six places to look, none agreeing on timestamps, and the bug is
always in the interleaving.
super-log converges all of it on one process and one screen:
| Group | What is in it |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **apps** | C++ (spdlog sink and nativeSN_LOG), plain C (one header), C# / .NET (BCL only — console, ASP.NET, Unity profiles, Xbox Dev Mode), Rust (tracing), Python (logging), Go (log/slog), Java, Kotlin and Scala (a **drop-in SLF4J backend** — swap your logging backend, no code change — plus Log4j 2 and Logback appenders, and java.util.logging), Swift, Fortran, OCaml, Haskell, Lean 4, Ruby and Rails (a drop-in ::Logger), Perl (core modules only), Lua (5.1+, PUC or LuaJIT), Zig (@cImport of the C header), COBOL (riding the C SDK, yes really), POSIX sh, and JS for Node, the browser and React Native — where console, fetch and WebGL are captured too. Anything else with a C FFI links one object: cc -DSUPERLOG_API= -c impl.c |
| **OpenTelemetry** | already instrumented with OTel? Join the bench with**no new SDK** — point any exporter at 127.0.0.1:4318 (OTEL_EXPORTER_OTLP_ENDPOINT, the standard port, zero config). Logs, metrics and traces over OTLP/JSON **and** OTLP/protobuf; severityNumber maps to levels, each service.name becomes an otlp. topic, and an OTel span's trace_id **becomes the bench's trace** — one /recent?trace= returns the OTel spans and the bench's own lines as a single story. And the **reverse**: superlog-otlp-export feeds any OTLP backend or collector from the bench (OTLP/JSON logs + gauge metrics), so the bench is a two-way OTLP member, not a walled garden |
| **GPU and graphics** | Metal and CUDA kernel timings, WebGL context loss and shader failures, and the card itself throughnvidia-smi, rocm-smi or ioreg |
| **devices and boards** | iOS and Android over USB, serial consoles reading ESP-IDF, Zephyr and bracketed formats, ROS 2/rosout, and **drones over MAVLink** (ArduPilot/PX4 — battery, GPS fix, mode/arm, failsafes and the flight controller's own STATUSTEXT, from a UDP stream or a .tlog) |
| **machines, services** | OS logs on macOS, Linux and Windows; ~20 known services (postgres, nginx, redis, kafka…); Unity and Unreal Engine editor logs, level-parsed (Blender and AutoCAD by recipe); Docker containers; any remote host over ssh; power draw, thermals and top energy consumers (macOS); crash reports, kernel panics, shutdown causes, volume and sleep/wake events (macOS); filesystem changes down to the changed LINES, diffed in real time; big downloads — a Hugging Face model, shard by shard — with stall alarms; other hubs, bridged whole; and**every version under the bench** — OS, compilers, runtimes, databases and every package the package manager knows — diffed, so "it worked yesterday" finally has an answer |