Logging and Structured Telemetry

Structured telemetry is what makes short-lived serverless executions diagnosable after they disappear. A function may run for only a few hundred milliseconds, but the logs and metadata it emits can still tell operators which request it handled, which tenant it affected, which event triggered it, which dependency call failed, and whether the failure is isolated or systemic.

Plain text logs are rarely enough in a serverless platform. There are too many small executions and too many parallel paths. Logs need structure so they can be filtered, aggregated, and correlated across services and invocations.

    flowchart LR
	    A["Request or event"] --> B["Function"]
	    B --> C["Structured log entry"]
	    C --> D["Central log store"]
	    D --> E["Search by correlation ID"]

What to notice:

• the important unit is not just the message text but the attached context
• a correlation identifier lets operators reconstruct one workflow across many executions
• logs are useful when they are queryable, not just when they exist

What Good Serverless Logs Contain

Useful log entries usually include:

• request ID or event ID
• correlation ID across downstream hops
• function or workflow name
• tenant or subject context when safe to include
• dependency name and latency
• outcome, error code, and retry attempt when relevant

The anti-pattern is to log generic strings like “processing started” or “failed to handle request” with no identifying context. Those lines multiply quickly and explain nothing.

 1{
 2  "level": "info",
 3  "message": "invoice generation completed",
 4  "requestId": "req-91f2",
 5  "correlationId": "corr-7b55",
 6  "workflow": "monthly-billing-close",
 7  "tenantId": "tenant-204",
 8  "invoiceId": "inv-881",
 9  "durationMs": 143,
10  "attempt": 1
11}

1export function logInfo(message: string, fields: Record<string, unknown>) {
2  console.log(JSON.stringify({
3    level: "info",
4    message,
5    timestamp: new Date().toISOString(),
6    ...fields,
7  }));
8}

What this demonstrates:

• logs are structured as machine-readable records
• correlation and workflow context travel with the message
• latency and attempt count help explain retry behavior and performance

Correlation IDs Matter More in Event-Driven Paths

In a monolithic request path, one trace can often explain the whole interaction. In serverless systems, the path may cross:

• an API gateway
• a function
• a queue
• another function
• a workflow engine
• a storage event

That makes correlation IDs essential. Each downstream component should either preserve the current correlation ID or derive one child context in a consistent way.

Log for Diagnosis, Not for Memory Dumps

Structured logging should not become “dump the entire payload.” Sensitive fields, large objects, and raw secrets create security risk and noisy telemetry. The strongest logs include the identity of the object and the outcome of the step, not a blind serialization of everything the function saw.

Common Mistakes

• using free-form text logs with no stable fields
• failing to propagate correlation IDs into downstream async work
• logging raw secrets, tokens, or full payloads unnecessarily
• emitting high-volume debug noise without clear signal value

Design Review Question

A payment workflow spans an API, a queue, two functions, and a reconciliation step. Operators can see that failures happened, but they cannot reconstruct the path of one customer request across those components. What is missing first?

The stronger answer is consistent correlation context and structured logs, not more log volume. Without a shared identifier and stable fields across hops, the platform produces telemetry that is large but not connected.

Check Your Understanding