Support NDJSON logging

[roderik]

Describe the feature

This is a common question we get to better ingest the logs into observability stacks

Additional information

• Would you be willing to help implement this feature?

[pi0]

Do you suggest a standard format or have examples of popular web servers outputting json?

[roderik]

The benefit of json logging is that you do not really need a parser or specific format, just throw it in an Loki/Grafana, ELK stack, Datadog, Sentry and these tools parse out the fields and you can search and query.

This format for nginx would probably work (but I assume with less fields when I look at the current output https://betterstack.com/community/guides/logging/how-to-view-and-configure-nginx-access-and-error-logs/

Easiest way to get this off the shelf is add --json parameter and then instead of printing a pretty string printing json stringify of an object with the same info.

However, stringify for high volume use cases has performance issues I think. Pino is a great and super fast logger. It defaults to json logging (would use this in --prod mode but you could stick to --json) but in non prod mode you can enable the pretty printer which is very close to the current pretty format. It does add a dependency though.

More inspiration from NestJS where you also have the two options and available source on how they do it. Even though we typically use Pino here as well via a plugin.

[pi0]

Feel free to open a draft PR to support json: true (for logger middleware) + --json flag (for CLI) 👍🏼

---

My main question is what the JSON format (keys) is best for devops and log collectors working out of the box.

There is Open telemetry Semantic conventions (http)

// HTTP Response
{"timestamp":"2025-09-25T09:12:34.123Z","http.request.method":"GET","url.path":"/v1/users/42","http.response.status_code":200,"http.response.body.size":8123,"server.duration_ms":23}


// HTTP Error
{"timestamp":"2025-09-25T09:13:02.987Z","http.request.method":"POST","url.path":"/v1/users","http.response.status_code":500,"server.duration_ms":6,"exception.type":"HTTPError","exception.message":"..."}

(note: duration_ms is custom, date is ISO8601 with Date.toISOString())

Also found Elastic Common Schema

// HTTP Response
{"@timestamp":"2025-09-25T09:12:34.123Z","http.request.method":"GET","url.path":"/v1/users/42","http.response.status_code":200,"event.duration":23000000,"http.response.body.bytes":8123}

// HTTP Error
{"@timestamp":"2025-09-25T09:13:02.987Z","http.request.method":"POST","url.path":"/v1/users","http.response.status_code":500,"event.duration":6000000,"error.type":"HTTPError","error.message":"..."}

We can support presets like json: boolean "otel" | "ecs", --json <preset> and default to one of these.

---

(AI-generated) Regarding the default, it seems otel might be a better bet:

Collectors that handle OTel (OTLP) logs:

• OpenTelemetry Collector — reads NDJSON via filelog receiver; exports OTLP to many backends (vendor-neutral hub). ([Honeycomb]1)
• Fluent Bit — can ship logs to an OpenTelemetry endpoint (OTLP/HTTP output). ([docs.fluentbit.io]2)
• Grafana Loki (backend) — natively accepts OTel logs over HTTP; use OTel Collector otlphttp exporter (or Grafana Alloy). ([Grafana Labs]3)
• Vector — has OTel source/sink (still evolving; check docs/issues if you plan pure OTLP → OTLP). ([vector.dev]4)
• Datadog — accepts OTLP logs agentlessly; or use OTel Collector with a Datadog exporter. ([docs.datadoghq.com]5)
• VictoriaLogs — OTLP/HTTP logs endpoint supported. ([docs.victoriametrics.com]6)
• (Ecosystem note): OTel logs are a first-class signal in OTel; logs integrate with existing logging libs/collectors. ([OpenTelemetry]7)

Collectors that are ECS-first (Elastic style) and NDJSON-friendly:

• Filebeat / Elastic Agent (Beats) — native ECS; can decode one-line JSON and map fields. ([Elastic]8)
• Logstash — ECS compatibility mode on by default in 8.x; schema-aware pipelines. ([Elastic]9)
• OpenSearch stack**/**pipelines — largely ECS-compatible due to lineage; many users run ECS fields unchanged. ([Elastic]10)

Collectors that are schema-agnostic (can pass NDJSON; not “OTel/ECS by default”):

• Promtail / Grafana Alloy — scrape NDJSON; commonly forward to Loki. For OTel, prefer OTel Collector → Loki OTLP flow. ([Grafana Labs]3)

[pi0]

@roderik reopened since it is still a nice idea to have! (LMK if prefer a new issue if not intrested anymore in notifications)

[pi0x]

Note

AI-generated (Claude) analysis, reviewed before posting.

After comparing the two candidates, suggestion is to ship a single NDJSON format with OTel semantic-convention keys — and skip the ecs preset:

• Elastic donated ECS to OpenTelemetry (2023) and the schemas are merging, with OTel semconv as the surviving namespace. An ECS preset would double the test/docs surface for a format that's being absorbed anyway.
• Every collector listed above either speaks OTel natively or is schema-agnostic; anyone with a hard ECS requirement already runs a collector that can rename a handful of fields.

Proposed format (flat dotted keys — cheapest to serialize, Datadog auto-expands dots, Elastic handles them natively):

{"time":"2025-09-25T09:12:34.123Z","level":"info","msg":"GET /v1/users/42 200","http.request.method":"GET","url.path":"/v1/users/42","http.response.status_code":200,"duration_ms":23.4}

{"time":"2025-09-25T09:13:02.987Z","level":"error","msg":"POST /v1/users 500","http.request.method":"POST","url.path":"/v1/users","http.response.status_code":500,"duration_ms":6.1,"error.type":"HTTPError","error.message":"..."}

Notes on the fields:

• level + msg aren't in the earlier sketch but are worth adding: Loki/Datadog/Grafana derive severity from level, and a short msg makes UIs with a message column readable.
• duration_ms: OTel's official unit is seconds and ECS's is nanoseconds — both hostile to humans; an explicit _ms suffix is unambiguous.
• error.type/error.message instead of exception.* (that's the span-event namespace; error.* is the attribute namespace and matches ECS too).
• Log url.path (+ url.query when present) rather than the full URL to limit cardinality/PII.

API shape:

• JS: log({ format: "json" }), with format: (info) => string as the escape hatch that replaces presets.
• CLI: --json; optionally default to JSON under --prod when stdout is not a TTY.
• When JSON mode is on, the startup banner should go to stderr (or become a {"event":"listening",...} record) so stdout stays pure NDJSON — interleaved pretty output is what breaks filelog-receiver pipelines in practice.
• No pino dependency needed: fixed-shape access log + JSON.stringify on a small flat object is plenty, keeping srvx zero-dep.