Deadline exceed in DataDog exporter
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- aws, docker, go
- Lĩnh vực
- cloud, observability-sre
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện các trace, log và hoạt động xuất metric đã được cấu hình với custom layer-collector/0.8.0 và datadogexporter v0.103.0, sau đó kiểm tra các đường dẫn timeout được nêu trong datadogexporter/traces_exporter.go:181 và exporterhelper/common.go:296. Hoàn thành có nghĩa là xác định nguyên nhân của các lỗi context deadline và xác nhận việc xuất dữ liệu đáng tin cậy sang DataDog mà không có payload bị loại bỏ hoặc retries bị cạn kiệt.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 433
- Fork
- 249
- Merge trung bình
- 1 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 39
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của open-telemetry/opentelemetry-lambda
-
enhancement ruby
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
open-telemetry/opentelemetry-lambda#2741 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
processor/cold_start
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
open-telemetry/opentelemetry-lambda#2738 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Fix install-toolsĐang mởgo
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
open-telemetry/opentelemetry-lambda#2736 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Use node-sdk package for layerĐang mởenhancement javascript
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
open-telemetry/opentelemetry-lambda#2744 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
enhancement python
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
open-telemetry/opentelemetry-lambda#2742 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của open-telemetry/opentelemetry-lambda
Issue tương tự
-
[bug]: scan-all update-schedule does not auto-convert 5-field cron expressions as documentedCó thể đã có người làm @vishnums2k5 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
goharbor/harbor-cli#1143 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 8 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
--info inline-right:PREFIX leaves the first character of the prefix when the info gets shorterĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
rossoctl/context-guru#1053 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] EphemeralJob matches every pod in the namespace when spec.selector is emptyCó thể đã có người làm @vishnums2k5 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
openkruise/kruise#2656 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày