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)