mRelic and the Death of tail -f

Beautiful log monitoring for any application, powered by fluent-bit and Next.js.

shobhit99, Creator · mrelic README

The stdout Breaking Point

Modern local development is a masterclass in context switching. You boot up a Next.js frontend, a Go backend API, and a Redis worker. Suddenly, your terminal is a chaotic waterfall of interleaved, unformatted text. Developers are forced to visually parse these logs across multiple Tmux panes, a cognitive tax that drains productivity.

The standard solution is to endure the mess or spend hours configuring a heavy local observability stack. mRelic offers a third path. It provides a GUI-first antidote to terminal fatigue.

The Invisible Local Sidecar

When developers hear about a new observability tool, their immediate reaction is skepticism. No one wants to add OpenTelemetry SDKs to their codebase just to trace bugs on localhost. mRelic bypasses this friction entirely using a zero-config Unix pipe pattern.

The core ingestion mechanism is practically invisible. By wrapping a standard command, such as executing mrelic npm start, the tool uses a shell script to siphon standard output directly into a local Node.js processor. This processor reads the stream line-by-line, attempting to parse JSON. If it encounters raw text, it neatly wraps the string into a structured log schema.

Crucially, the sidecar auto-detects the service name by inspecting the current working directory. This simple heuristic eliminates the need for manual configuration files.

Schema-on-Read with SQLite

Unlike many dev tools that keep logs in volatile memory, mRelic requires a persistent, high-performance storage engine. The project relies on better-sqlite3 for synchronous, low-latency writes directly to disk.

db.exec(`
  CREATE TABLE IF NOT EXISTS logs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp TEXT NOT NULL,
    level TEXT NOT NULL,
    service TEXT NOT NULL,
    message TEXT NOT NULL,
    data TEXT
  );
  CREATE INDEX IF NOT EXISTS idx_logs_timestamp ON logs(timestamp);
  CREATE INDEX IF NOT EXISTS idx_logs_level ON logs(level);
  CREATE INDEX IF NOT EXISTS idx_logs_service ON logs(service);
`);

The schema strategy is deliberate. It indexes only the most critical query dimensions: timestamp, level, and service. All other arbitrary, language-specific metadata is packed into a single stringified JSON column. This schema-on-read approach allows mRelic to ingest logs from Go, Python, and Node simultaneously without requiring complex database migrations.

Building a Search DSL from Scratch

Many developer tools fail at search. Simple string matching is rarely enough when debugging complex distributed logic. In src/lib/searchParser.ts, mRelic tackles this by implementing a custom, Lucene-like parser explicitly for local log filtering.

The query engine handles negation, exact quotes, and wildcards. It employs a hybrid filtering strategy to maintain performance. Simple queries hit the SQLite index directly. For complex DSL queries, the system fetches large batches of records and evaluates them in-memory using TypeScript regex. This pragmatic tradeoff avoids the immense complexity of writing a SQL generator for a custom language.

The Sweet Spot of Local Observability

The competitive landscape for local logging is starkly divided. On one end, you have terminal UIs which are lightweight but lack a rich visual interface. On the other end, you have production stacks like Grafana Loki or ELK, which require massive Docker Compose files just to get started.

mRelic finds the sweet spot. By combining a zero-configuration ingestion pipeline with a fast, embedded database and a modern web frontend, it brings the polish of enterprise observability to the local machine without the associated operational baggage.