kmdreko's

A SIMPLE BLOG

A Simple Log Viewer: Venator

JANUARY 24, 2025 | RUST, TRACING, OPENTELEMETRY

Over the past six months' worth of free time I have been working on Venator - an application for visualizing log and trace data from the Rust tracing ecosystem and OpenTelemetry exporters. Contrary to the title, this ended up far from simple but I'm very glad I worked on it.

The app has three main views: one for showing events, one for showing spans, and one dedicated for traces which correlate spans and events originating from some initial action. On each view it supports complex queries for filtering the data based on attributes, source information, or other metrics. Each view also shows a graph over time that not only gives you an overview of how the data is distributed, but is also interactive for navigating to points of interest. And most importantly, each view includes a table with customizable columns and a detailed panel that shows all the data for each entity.

Rust Tracing

My motivation for developing Venator was of course out of my own self interests: I wanted some tool to help me manage data produced by Rust programs instrumented with the tracing crate. I think tracing is a phenomenal library for structured logging, but I was disatisfied with my options for utilizing it.

The name "Venator" is a thematic play off of Jaeger, which was the closest tool out there but I personally didn't find it useful enough for my needs. My main inspiration was Datadog - which I find incredibly useful but is also an unreasonable option for local and personal uses.

So I built this app to be tailored specifically for me. I built it around the tracing subscriber API which simply forwards all events to my UI. Of course the Venator application itself is also written in Rust with the UI in SolidJS and using Tauri for the integration and platform support.

OpenTelemetry

Even though I primarily built it for myself, I still wanted to provide it to everyone in hopes that others would also find it useful. In striving to make it more generally applicable though, the obvious next question is "why limit yourself to tracing when OpenTelemetry is already more prevalent?". So that is what I did.

I did not throw away my efforts tailoring the app to tracing - I could have since using tracing with an OpenTelemetry exporter is an option - but I kept it since the tracing-specific flow includes some data that is lost when coerced to OpenTelemetry and Rust users using my tracing subscriber would it much simpler to setup compared to the same with OpenTelemetry.

Supporting OpenTelemetry also introduces a lot of unknowns; I have much less experience with it and no experience with using the OpenTelemetry SDKs of other languages. Of course all should follow the specification but quirks happen and users likewise have differing ideas on how certain data should be presented within the context of their language. But I'll face those challenges as they arise.