Hugh KaznowskiandClaude Sonnet 5
e397f9fbdb
Collapse the Params-panel ParamDeclaration and the metric-embedded RegexToMetricPrimitiveMatcher into a single ParamDeclaration type (name, regex/capture-group-or-json-field-path, kind). MetricDeclaration now references params by name via label_params: Vec<String> and value_param: Option<String> instead of embedding its own extractor per param, so a param declared once in the Params panel can be reused as a label or value by any number of metrics. Declaring a metric that references an undeclared param name is now rejected at declare-time. Backend: - src/data_value.rs: unified ParamDeclaration struct; MetricDeclaration data value now carries label_params/value_param instead of a Vec of inline matchers. - src/engine.rs: DeclareParamRequest is now an alias for ParamDeclaration; DeclareMetricRequest carries label_params/ value_param; validate_metric_request checks referenced param names against the declared-param store; apply_metric_to_log resolves label_params/value_param against a per-ingest resolved-param map instead of reading an inline matcher list. - src/profile.rs: MetricDeclarationRecord carries label_params/ value_param plus a private, serialize-skipped legacy_params field that only ever gets populated by deserializing a pre-037 profile file's old "params" key. ProfileStore::load migrates any such legacy metric into the unified shape (reusing an existing same-shaped bare param by name, or creating one implicitly named "<metric_name>.<param_name>"), then persists the migrated store so the on-disk file only carries the legacy shape once. Migration is idempotent (deterministic naming) and covered by dedicated tests. - src/api.rs / src/dto.rs: MetricDeclarationDto and the declare/update metric response bodies updated to the new shape. Frontend: - webapp/src/lib/api.ts: MetricDeclaration type now has label_params/ value_param; MetricParamMatcher/ParamRole types removed. - webapp/src/components/Metrics.tsx: the declaration form now fetches declared params and lets you check off label params / pick a value param from that list, instead of re-entering a regex/capture-group/ kind per metric param. Leaves ticket 038 (duration as a derived param kind) and 039 (param query resolving declared params) untouched, as scoped. 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