Integrate evlog
Once you understand the logging modes, there are two questions left to answer before evlog is wired into your stack:
- Where does the logger live? → Pick a framework integration. Each integration creates the logger on every request, attaches it to the context, and emits the wide event when the response ends. You don't manage the lifecycle.
- Where do events go? → Pick one or more adapters. Adapters ship the wide event to an external observability platform — Axiom, Datadog, Sentry, PostHog, OTLP-compatible systems, file system, NuxtHub.
The two are independent. A Nuxt app can drain to Axiom, an Express app can drain to OTLP + Sentry simultaneously, a SvelteKit app can drain to a local file in dev and to Datadog in production.
Don't see your framework?
Check Custom Framework Integration. The evlog/toolkit package exposes the same building blocks every built-in integration uses — most HTTP frameworks need ~30 lines of glue.
Don't see your destination?
Check Custom Drains. defineHttpDrain from evlog/toolkit ships any backend with a single function and gives you batching, retries, timeouts, and identity headers for free.
telemetry
What the evlog CLI collects about its own usage, how to see it, and the three ways to turn it off — DO_NOT_TRACK, EVLOG_TELEMETRY=0, or evlog telemetry disable.
Overview
Send your logs to external services with evlog adapters. Built-in support for popular observability platforms and custom destinations.