Luster is an observability toolkit for Rails that doesn’t care which backend you use. Datadog today, OpenTelemetry tomorrow, same instrumentation code either way. One config change swaps the entire backend. Your code stays the same.
The out-of-the-box instrumentation from Datadog and OpenTelemetry is the bare minimum—enough to know something happened, not enough to know what went wrong. Luster’s docs push you toward manual instrumentation: wrapping your service objects, your critical paths, the code that actually matters. Auto-instrumentation gets you started; deliberate instrumentation gets you answers.
Why it exists
Most observability tools marry you to a vendor. You write Datadog-specific code, then six months later someone decides you’re moving to Honeycomb, and now you’re rewriting instrumentation across fifty services. Or you go with OpenTelemetry from the start—which is the right call—but the Rails integration story is scattered across a dozen gems with varying levels of maintenance.
The other problem is detection. N+1 queries, memory bloat, duplicate queries, slow queries—these are runtime problems. Static analysis doesn’t catch them. You find out in production, usually from a customer complaint or an alert that fires at 3am. By then the damage is done.
Luster handles both. Write instrumentation once, run it anywhere. Detect problems before they become incidents.
How it works
Include a concern in your service classes. Luster wraps execution, tracks memory delta, records timing, catches errors, and reports everything to whatever backend you’ve configured. Controllers, jobs, Sidekiq workers, and rake tasks get instrumented automatically.
class ImportService
include Luster::Concerns::Instrumented
def call
# your code here
end
end
That’s it. Duration, memory change, GC runs, errors—all tracked. Tags flow through automatically.
The trackers
Nine detection engines hook into ActiveSupport notifications and watch for problems:
The duplicate query tracker normalizes SQL and catches repeated queries—the N+1 detector. The query pattern tracker flags missing indexes, unbounded SELECTs, and queries hitting slow thresholds. Memory bloat tracking watches GC runs, heap fragmentation, and allocation spikes. Database lock detection queries PostgreSQL for long-running locks before they cascade. The serialization tracker catches those 50MB Marshal dumps that shouldn’t exist.
Each tracker reports to your backend with configurable thresholds.
Context-aware configuration
Here’s the thing about thresholds: what’s bad in a web request isn’t necessarily bad in a background job, which isn’t necessarily bad in a migration. Three duplicate queries during a page load is a problem. Twenty during a nightly data import might be fine.
Luster knows the difference. Configure thresholds per context—request, job, rake, script—and each execution environment applies its own rules.
config.duplicate_query_tracker.threshold = {
request: 3,
job: 10,
rake: 50,
default: 5
}
No more global thresholds that are either too strict for batch jobs or too lenient for user-facing requests.
The backend abstraction
Both Datadog and OpenTelemetry implement the same interface. Histograms, counters, gauges, distributions, traces—all work identically. Default tags merge automatically. The backend handles the translation.
Luster.backend.current.metrics.histogram('query.duration', duration_ms, tags: ['table:users'])
That line works the same whether you’re shipping to Datadog’s agent or an OTLP collector. The decision about where metrics go lives in configuration, not scattered across your codebase.
Beyond what vendors give you
Datadog and OpenTelemetry’s Rails integrations hook into controllers, jobs, and database queries. That’s fine for knowing a request was slow. It’s useless for knowing why.
Luster gives you the tools to go deeper—instrument your service objects, your API clients, your data pipelines. The concern-based approach makes adding instrumentation trivial. The docs walk through exactly where to add it and what to track. The goal is observability that actually helps you debug, not just dashboards that confirm something is broken.
Dashboards included
Luster ships with pre-built dashboards for both Datadog and SigNoz. Import them and you’ve got visibility into request performance, job health, memory trends, query patterns, and error rates—all broken down by the tags and contexts you care about. No staring at a blank canvas trying to remember which metrics exist.
Origin
Built because I kept rewriting the same instrumentation code across projects, kept picking different backends depending on client requirements, and kept finding N+1s in production instead of development. Luster is the extraction of patterns I’d copy-pasted one too many times.