Deadline exceed in DataDog exporter
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
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- aws, docker, go
- Área
- cloud, observability-sre
Línea de trabajo
Comienza reproduciendo las trazas, los logs y la exportación de métricas configurados con custom layer-collector/0.8.0 y datadogexporter v0.103.0; después, inspecciona las rutas de timeout indicadas en datadogexporter/traces_exporter.go:181 y exporterhelper/common.go:296. Se considerará terminado cuando se haya identificado la causa de los errores de context deadline y confirmado una exportación fiable a DataDog sin payloads descartados ni reintentos agotados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
I am experiencing a deadline exceed issue on the DataDog exporter, as evidenced by the logs. This issue results in failed export attempts and subsequent retries.
Steps to reproduce
1. Configure the custom Docker image with the custom collector based on opentelemetry-lambda that includes the DataDog exporter.
2. Initiate data export (traces, logs, metrics).
3. Observe the logs for errors related to context deadlines being exceeded.
What did you expect to see?
I expected the data to be exported successfully to DataDog without any timeout errors.
What did you see instead?
The export requests failed with “context deadline exceeded” errors, resulting in retries and eventual dropping of the payloads. Here are some excerpts from the logs:
1719687286935 {"level":"warn","ts":1719687286.9350078,"caller":"[email protected]/batch_processor.go:263","msg":"Sender failed","kind":"processor","name":"batch","pipeline":"logs","error":"no more retries left: Post \"https://http-intake.logs.datadoghq.com/api/v2/logs?ddtags=service%3Akognitos.book.yaml%2Cenv%3Amain%2Cregion%3Aus-west-2%2Ccloud_provider%3Aaws%2Cos.type%3Alinux%2Cotel_source%3Adatadog_exporter\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"}
1719687286936 {"level":"error","ts":1719687286.9363096,"caller":"[email protected]/traces_exporter.go:181","msg":"Error posting hostname/tags series","kind":"exporter","data_type":"traces","name":"datadog","error":"max elapsed time expired Post \"https://api.datadoghq.com/api/v2/series\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)","stacktrace":"github.com/open-telemetry/opentelemetry-collector-contrib/exporter/datadogexporter.(*traceExporter).exportUsageMetrics\n\t/root/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/exporter/[email protected]/traces_exporter.go:181\ngithub.com/open-telemetry/opentelemetry-collector-contrib/exporter/datadogexporter.(*traceExporter).consumeTraces\n\t/root/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/exporter/[email protected]/traces_exporter.go:139\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*tracesRequest).Export\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/traces.go:59\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*timeoutSender).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/timeout_sender.go:43\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*baseRequestSender).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/common.go:37\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*tracesExporterWithObservability).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/traces.go:159\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*baseRequestSender).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/common.go:37\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*baseRequestSender).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/common.go:37\ngo.opentelemetry.io/collector/exporter/exporterhelper.(*baseExporter).send\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/common.go:294\ngo.opentelemetry.io/collector/exporter/exporterhelper.NewTracesRequestExporter.func1\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/exporterhelper/traces.go:134\ngo.opentelemetry.io/collector/consumer.ConsumeTracesFunc.ConsumeTraces\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/[email protected]/traces.go:25\ngo.opentelemetry.io/collector/processor/batchprocessor.(*batchTraces).export\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/processor/[email protected]/batch_processor.go:414\ngo.opentelemetry.io/collector/processor/batchprocessor.(*shard).sendItems\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/processor/[email protected]/batch_processor.go:261\ngo.opentelemetry.io/collector/processor/batchprocessor.(*shard).startLoop\n\t/root/go/pkg/mod/go.opentelemetry.io/collector/processor/[email protected]/batch_processor.go:223"}
What version of collector/language SDK version did you use?
Version: Custom layer-collector/0.8.0 + datadogexporter from v0.103.0
What language layer did you use?
Config: None. It is a custom runtime that includes the binary in extensions.
Additional context
Here is my configuration file:
receivers:
otlp:
protocols:
grpc:
endpoint: "127.0.0.1:4317"
hostmetrics:
collection_interval: 60s
scrapers:
paging:
metrics:
system.paging.utilization:
enabled: true
cpu:
metrics:
system.cpu.utilization:
enabled: true
disk:
filesystem:
metrics:
system.filesystem.utilization:
enabled: true
load:
memory:
network:
processes:
exporters:
datadog:
api:
key: ${secretsmanager:infrastructure/datadog_api_key}
sending_queue:
enabled: false
tls:
insecure: true
insecure_skip_verify: true
connectors:
datadog/connector:
processors:
resourcedetection:
detectors: ["lambda", "system"]
system:
hostname_sources: ["os"]
transform:
log_statements:
- context: resource
statements:
- delete_key(attributes, "service.version")
- set(attributes["service"], attributes["service.name"])
- delete_key(attributes, "service.name")
- context: log
statements:
- set(body, attributes["exception.message"]) where attributes["exception.message"] != nil
- set(attributes["error.stack"], attributes["exception.stacktrace"]) where attributes["exception.stacktrace"] != nil
- set(attributes["error.message"], attributes["exception.message"]) where attributes["exception.message"] != nil
- set(attributes["error.kind"], attributes["exception.kind"]) where attributes["exception.kind"] != nil
service:
telemetry:
logs:
level: "debug"
pipelines:
traces:
receivers: [otlp]
processors: [resourcedetection]
exporters: [datadog/connector]
traces/2:
receivers: [datadog/connector]
exporters: [datadog]
metrics:
receivers: [hostmetrics, otlp]
processors: [resourcedetection]
exporters: [datadog]
logs:
receivers: [otlp]
processors: [resourcedetection, transform]
exporters: [datadog]
Enabling/disabling sending_queue does not seem to do anything to prevent the errors. I did noticed that if I hit the service continuously some traces do get sent, but only a few.
What I discarded as potential solutions:
- Connectivity issues. DataDog has an API Key validation API calls that succeeds. If the service is hit constantly some traces get thru.
- Lenguaje dominante
- Go
- Estrellas
- 433
- Forks
- 249
- Merge medio
- 1 d 12 h
- PR fusionados (30 d)
- 39
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de open-telemetry/opentelemetry-lambda
-
enhancement ruby
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
open-telemetry/opentelemetry-lambda#2741 ·
Los mantenedores suelen responder en 2 días
-
processor/cold_start
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
open-telemetry/opentelemetry-lambda#2738 ·
Los mantenedores suelen responder en 2 días
-
Fix install-toolsAbiertogo
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
open-telemetry/opentelemetry-lambda#2736 ·
Los mantenedores suelen responder en 2 días
-
Use node-sdk package for layerAbiertoenhancement javascript
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
open-telemetry/opentelemetry-lambda#2744 ·
Los mantenedores suelen responder en 2 días
-
enhancement python
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
open-telemetry/opentelemetry-lambda#2742 ·
Los mantenedores suelen responder en 2 días
Todos los issues de open-telemetry/opentelemetry-lambda
Issues similares
-
Support kubevirt CRDsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rancher/rancher-ai-mcp#206 ·
Los mantenedores suelen responder en 1 día
-
test: make command and stdio startup tests portablePosiblemente ocupada @dajiaohuang la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
mark3labs/mcp-go#1220 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Project submission: Agent8088Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
open-telemetry/opentelemetry-go-compile-instrumentation#1743 ·
Los mantenedores suelen responder en 2 días
-
FindInBatches panics for non-positive batch sizesPosiblemente ocupada @Dazhou-del la tomó hoy. Abiertotype:with reproduction steps
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día