Hugh KaznowskiandClaude Sonnet 5
f48d3c6ffb
auto_declare_params (src/engine.rs) previously never overwrote or pruned a declaration, so a burst of unusual key=value-shaped lines could permanently inflate the params UI forever. A real macOS `log stream` dump (huig_dump.txt, copied into src/fixtures/log_stream_sample.txt) discovered 220 distinct auto-declared params from under 700 lines, mostly one-off WiFi/radio stat counters (20+ pairs on a single line), plus base64-blob false positives from key()'s greedy alnum matching landing right before `==` padding. Fix, combining two bounds per the ticket's options: - src/logfmt.rs: extract_pairs/pair now rejects a candidate pair whose bareword value starts with a bare '=' (looks_like_base64_padding_artifact) — the exact shape produced when a base64/hash blob's padding sits right after a run of alnum chars that key() consumed as if it were a key. - src/engine.rs: auto_declare_params now enforces a per-line cap (MAX_NEW_AUTO_PARAMS_PER_LINE = 8) on new params from one line, and a total ceiling (MAX_AUTO_DECLARED_PARAMS = 64) on auto-derived params overall — the per-line cap alone doesn't bound unbounded key *variety* across many lines, so both are needed. Also adds structured extraction for log stream's fixed-column shape (Timestamp Thread Type Activity PID TTL, then `process: message`): detect_format gains a new "log_stream" ottyl_fmt value (checked first, since it's the most specific of the four), and auto_declare_log_stream_params declares log_type/process/pid as standalone queryable params the first time such a line is seen — derived positionally from the column layout rather than =-scanning, so there's no ambiguity or false-positive risk. This is a separate always-attempted extraction alongside the existing key=value pass, not a replacement for it: a log stream line's message tail can still contain real key=value pairs (e.g. the WiFi stat lines) that auto_declare_params keeps discovering independently. This also fully addresses ticket 054, confirming huig_dump.txt is space-padded fixed-width columns, not TSV, and that no separate TSV format is needed. Throughput (src/fixtures/log_stream_sample.txt x50, release build): before (caps disabled) ~369k lines/sec, 206 auto-declared params; after (caps enabled) ~1.20M lines/sec, 64 auto-declared params — about 3.2x faster, confirming the ever-growing declaration set was the bottleneck rather than per-line regex/nom scanning cost. Removes tickets/050 and tickets/054 now that both are implemented. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o
ottyl
Observability for any command's terminal output — no logging backend, no agents, no config to ship.
your_app --verbose | ottyl
Pipe a program's stdout into ottyl and turn it into a searchable log timeline, ad-hoc metrics extracted from the log lines themselves, and Grafana-style dashboards — served from a single local binary, for the lifetime of that process:
- Search: A syntax-aware filter bar over your logs — regex matches and metric comparisons like
latency_ms[value]<200, with relative (5h,-3m) and absolute datetimes. - Log timeline: A bucketed bar chart of message volume over time, Kibana-style. Drag across it to set the active time range.
- Metrics from logs: Declare a metric by matching a regex against your log lines and extracting a value. It applies retroactively to everything already ingested, and to everything that follows.
- Dashboards: Bar, line, and pie chart panels driven by PromQL-style queries over your declared metrics.
- Mixed sources: Poll an existing Prometheus/OpenMetrics endpoint alongside log ingestion, in the same dashboard.
- Profiles: Parsing rules and dashboards are saved per app, so they're there again next time that app runs through ottyl.
Use cases
- Debugging a noisy CLI or long-running script, instead of scrolling a terminal buffer.
- Getting metrics and charts out of a program that only ever prints text.
- Local dashboards without standing up a metrics stack.
- Combining scraped Prometheus metrics with log-derived ones during a debugging session.
Get started
Requires Rust and Node.js. The webapp is built and embedded into the binary, so the result is a single self-contained executable.
git clone <this-repo>
cd ottyl
make build
your_app --verbose | ottyl
Or point it at a log file instead of stdin, and mix in a Prometheus/OpenMetrics endpoint:
ottyl --file /var/log/your_app.log --metrics-url http://localhost:9090/metrics
ottyl prints the URL of the local web server it starts (an OS-assigned free port by default; pin one with --port). See ottyl --help for the rest, including where settings and profiles live (--settings-path).
Full documentation — filtering syntax, parameters, metrics, dashboards — is built into the app itself, under the nav menu's docs section.
Development
make dev # frontend dev server with hot reload, proxying to a separately running `cargo run` backend
make test # backend + frontend tests
make lint # clippy + oxlint