Catch ControlTheory at Observability Summit: Stop Standing Up a Collector Just to Read Your Own Logs

Thursday, May 21 · 12:05pm CDT · Ballroom B (Level One)

Here’s the workflow most of us still run when we want to validate an OpenTelemetry instrumentation change: spin up a Collector. Wire in the debug exporter. Pipe it through tail -f. Squint at JSON. Fifteen lines of YAML to debug six lines of code.

The Collector is the right tool for production pipelines. It is not the right tool for “did order_id actually make it onto the log record?” or “why is this exception getting logged at INFO?” Those are the bugs you ship every week, and the debug exporter doesn’t help you catch them.

That’s the gap our co-founder and CPO, Jon Reeve, is closing in his lightning talk at Observability Summit this Thursday.

The talk

“From Collector to Terminal: A Better Way to See Your OpenTelemetry Logs“ introduces Gonzo — an open-source, OTLP-native terminal UI that’s a single binary, no YAML, no backend. gRPC on :4317, HTTP on :4318. Point your app’s OTLP exporter at it and watch your telemetry stream by with structure you can actually read.

brew install gonzo
gonzo --otlp-enabled

brew install gonzo
gonzo --otlp-enabled

That’s the whole setup.

Three ways teams are using it

1. Validate instrumentation at the source. Write a log line, run your app, see exactly what landed. Catch missing attributes and wrong severity before they ship.

2. Iterate locally with a tight feedback loop — especially when an AI assistant is writing the instrumentation. No backend round-trip, no waiting for ingest. Structure for humans is structure for agents.

3. Debug Collector pipelines end-to-end. Point your debug exporter at Gonzo’s OTLP receiver and validate filelog, k8sattributes, and transform processors without standing up a backend.

Why this matters

Gonzo is at 2,700+ stars on GitHub and MIT-licensed. If you’ve ever wanted to see your OTel logs the way the SDK actually emitted them — without standing up infrastructure to do it — this is the talk.

And when you’re ready to close the loop between AI-generated code and runtime reality, Dstl8 is continuous runtime feedback for what ships next — investigating, correlating, and feeding runtime context back into Claude Code, Cursor, and Codex – built on Open Telemetry. But that’s a conversation for after the talk.

Catch the session

• 📅 Thursday, May 21 · 12:05–12:15pm CDT
• 📍 Level One, Ballroom B
• 🎤 Jon Reeve · Co-founder & CPO, ControlTheory

If you’re at the Summit, come find us.

Frequently asked questions

What is Gonzo?

Gonzo is an open-source, OTLP-native terminal UI for OpenTelemetry logs. It’s a single binary with no YAML config and no backend — it accepts OTLP over gRPC on port 4317 and HTTP on port 4318. Maintained by ControlTheory, 2,700+ stars on GitHub, MIT-licensed.

How do I view OpenTelemetry logs in the terminal?

Install Gonzo and run it as an OTLP receiver: brew install gonzo && gonzo --otlp-enabled. Then point your application’s OTLP exporter (or your OpenTelemetry Collector’s debug or otlp exporter) at localhost:4317. Logs stream into the terminal with structured fields, filters, and real-time pattern detection.

How is Gonzo different from the OpenTelemetry Collector’s debug exporter?

The Collector’s debug exporter dumps raw OTLP output to stdout. Gonzo is purpose-built for reading it — structured field display, attribute filtering, severity views, and pattern detection. You also don’t need to stand up a Collector at all: point your app’s OTLP SDK exporter directly at Gonzo when you’re validating instrumentation.

Do I need an observability backend to validate OpenTelemetry instrumentation?

No. Gonzo runs locally as an OTLP receiver, so you can write a log line, run your app, and see exactly what landed on the wire — without standing up Loki, Datadog, or any other backend. This makes it fast to catch missing attributes, wrong severity levels, and broken processors at the source, before they ship.

What’s the difference between Gonzo and Dstl8?

Gonzo is the local, terminal-native tool for validating instrumentation and pipelines — open source, no account, no backend. Dstl8 is continuous runtime feedback for AI-generated code: it investigates, correlates, reasons, and remembers runtime problems across Supabase, Vercel, Railway, AWS, Kubernetes, and OpenTelemetry, then streams the context back into Claude Code, Cursor, and Codex. Use Gonzo when you’re debugging instrumentation; add Dstl8 when you need to close the loop between AI-generated code and runtime reality.