Node layer never flushes LoggerProvider on invocation completion — logs silently dropped without manual forceFlush()

Abierto
  • ¿Algo no está bien?
#2,537 1 comentario 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
aws, node.js, typescript
Área
cloud, observability

Línea de trabajo

Lee nodejs/packages/layer/src/wrapper.ts, comenzando por la construcción de LoggerProvider y la ruta de finalización del handler envuelto; inspecciona también si existe una ruta SHUTDOWN de Lambda Extensions API. Reproduce el problema con el handler y el endpoint OTLP proporcionados y verifica que los logs emitidos sin forceFlush() manual se entreguen antes de que finalice la invocación o se produzca el shutdown.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug javascript

Describe the bug
When using the Node layer with AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler and OTLP logs export, logs emitted via the Logs API are unreliably delivered to the backend. They are only reliably delivered if the application explicitly calls forceFlush() on the logger provider before the handler returns. wrapper.ts constructs the LoggerProvider with a BatchLogRecordProcessor but no code path calls forceFlush()/shutdown() on it after the wrapped handler resolves, nor on a Lambda Extensions API SHUTDOWN event. AWS may freeze the execution environment shortly after the handler returns, before the batch processor's timer fires, dropping any log not yet exported.

Steps to reproduce
Deploy a Lambda with the layer below and AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler, OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=<your OTLP endpoint>, using this handler:

import { logs, SeverityNumber } from '@opentelemetry/api-logs'
import { randomUUID } from 'node:crypto'

export async function handler() {
    const experimentId = randomUUID()

    logs.getLogger('otel-logs').emit({
        body: 'Lambda test log',
        severityNumber: SeverityNumber.INFO,
        severityText: 'INFO',
        attributes: {
            experiment_id: experimentId,
        },
    })

    // works only with this line uncommented
    // await (logs.getLoggerProvider() as any).forceFlush?.()

    return {
        experimentId,
    }
}

Invoke repeatedly with the forceFlush() line commented out: log records are missing in the backend intermittently. Uncommenting the forceFlush() line (or alternatively sleeping ~5s before returning) makes delivery reliable.

What did you expect to see?
Logs emitted during a Lambda invocation are flushed/delivered automatically by the layer before the execution environment is frozen, the same "zero code change" guarantee the layer provides for traces.

What did you see instead?
Log records queued in the (default) BatchLogRecordProcessor are lost intermittently, with no application-level indication of the drop.

What version of collector/language SDK version did you use?
Version: layer opentelemetry-nodejs-0_23_0 (arn:aws:lambda:eu-central-1:184161586896:layer:opentelemetry-nodejs-0_23_0:1)

What language layer did you use?
Config: Node.js

Additional context
Relevant code: wrapper.ts constructs the LoggerProvider with a BatchLogRecordProcessor (no schedule-delay override), but no flush/shutdown call exists in the wrapper for the logger (or tracer/meter) provider.

Suggested fix: flush all registered providers (logger, tracer, meter) automatically once the wrapped handler settles, before returning control to the Lambda runtime, and/or register a Lambda Extensions API SHUTDOWN handler to flush on environment termination so in-flight logs aren't lost if the process is killed abnormally.

Workaround: manually call await (logs.getLoggerProvider() as any).forceFlush?.() at the end of every handler.

Possibly related (metrics, not logs, but similar auto-flush gap): #1949

Lenguaje dominante
Go
Estrellas
433
Forks
249
Merge medio
1 d 12 h
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de open-telemetry/opentelemetry-lambda

Todos los issues de open-telemetry/opentelemetry-lambda

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.