การบันทึกแบบมีโครงสร้างด้วยรหัสเชื่อมโยง

In production, logs are read by machines before humans. A line like console.log('User ' + id + ' failed login') is a free-form string: to find it later you must write brittle regex and you cannot aggregate or filter reliably.

Structured logging emits each log as a JSON object with consistent fields. Log aggregators (Loki, Elasticsearch, Datadog, CloudWatch) index those fields so you can query level="error" AND userId=42 instantly.

• Free-form: easy to write, painful to query.
• Structured: one JSON object per line (NDJSON), trivially parseable.

The core idea is small: build a plain object, stamp it with a level and timestamp, and write one JSON string per line to stdout. The runtime or container collects stdout and ships it to your aggregator.

Each log is a single line of valid JSON. This format is called NDJSON (newline-delimited JSON) and every modern log backend understands it.

Hand-rolling works for learning, but production apps use a battle-tested logger. pino is the de-facto choice for Node.js: it is extremely fast because it serializes JSON in a worker-friendly way and writes asynchronously.

• logger.info(obj, msg) — the first arg is the object of fields, the second is the message string.
• Levels: trace, debug, info, warn, error, fatal.
• In production you pipe stdout to pino-pretty only in dev; raw JSON goes to prod.

Under load, hundreds of requests interleave their logs. When user 42 reports an error, you need to see every log line that belongs to their request — across middleware, services, and database calls.

The solution is a correlation ID (also called request ID or trace ID): a unique identifier generated once per request and attached to every log emitted while handling that request.

• Query correlationId="7f3a..." and the aggregator reconstructs the whole request timeline.
• If the ID arrives in an incoming header, you can correlate logs across services.

At the edge of your system, read an incoming correlation header if a caller (gateway, upstream service) already set one; otherwise generate a fresh UUID. Always echo it back in the response so clients and proxies can record it too.

Standard header names are x-request-id or x-correlation-id. Reusing an inbound ID is what makes tracing work across service boundaries.

The obvious move is to pass req.correlationId as an argument into every function and every log call. This works but does not scale: a deep call stack (controller → service → repository → helper) forces you to thread the ID through functions that otherwise have no reason to know about it.

This is prop drilling for the backend. You want the ID available implicitly to any code running during the request — without changing every function signature.

Node.js ships AsyncLocalStorage (in the async_hooks module). It creates a store that stays bound to the current asynchronous execution context — surviving across await, callbacks, timers, and promises — without being shared between concurrent requests.

Think of it as request-scoped thread-local storage. You call als.run(store, callback) once per request; anywhere inside that callback (no matter how deep or how many awaits later) als.getStore() returns the same store.

Replace the naive middleware: instead of attaching the ID to req, run the rest of the request inside als.run() with the ID in the store. Now every line of code executed for this request — controllers, services, DB callbacks — can reach the ID via getStore().

Crucially, you must call next() inside the run callback so the downstream handlers inherit the context.

The payoff: wrap your logger so it reads the correlation ID from AsyncLocalStorage automatically. Application code calls log.info('saved order') with no ID argument, yet every emitted line carries the right correlationId.

With pino you express this declaratively using the mixin option, which merges extra fields into every log record at write time.

Correlation only spans services if you forward the ID on outbound requests. When your service calls another HTTP API, read the ID from context and set it as a header. The downstream service's middleware will reuse it, so both services' logs share one ID.

The same principle applies to message queues (put the ID in message metadata) and background jobs (store it on the job payload).

A few rules keep your structured logs clean and safe:

• Never log secrets or PII — passwords, tokens, full card numbers. Configure pino redact paths (e.g. ['req.headers.authorization', '*.password']).
• Log at the right level — info for business events, warn for recoverable issues, error with the serialized error object for failures.
• Keep field names stable — correlationId always means the same thing; dashboards and alerts depend on it.
• One JSON object per line — do not pretty-print in production; it breaks NDJSON parsing.

You need the correlation ID available to every function in a deep call stack during a request, without passing it as an argument and without leaking it between concurrent requests. What is the correct mechanism in Node.js?

You learned how to make logs both machine-parseable and traceable:

• Structured logging emits one JSON object per line (NDJSON) so aggregators can index and query fields.
• pino is the standard fast Node.js logger; the field object comes first, the message second.
• A correlation ID is generated or reused from an inbound header once per request and echoed in the response.
• AsyncLocalStorage threads that ID through the whole async call stack without changing function signatures, and isolates concurrent requests.
• Pino's mixin auto-injects the ID into every log; forwarding it as an outbound header extends tracing across services.
• Practice good hygiene: redact secrets, use correct levels, keep field names stable, never pretty-print in production.