Integrate evlog

Once you understand the logging modes, there are two questions left to answer before evlog is wired into your stack:

1. 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.
2. 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.

Once something is wired, try evlog map (npx @evlog/cli map) to see which entry points are still dark — or evlog doctor if nothing is showing up. Separate early package; optional, worth a run.

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.