[OTEL logs] OTel appender: custom retry budget + maxQueueSize - #290772
Open
jesuswr wants to merge 6 commits into
Open
[OTEL logs] OTel appender: custom retry budget + maxQueueSize#290772jesuswr wants to merge 6 commits into
jesuswr wants to merge 6 commits into
Conversation
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
Co-authored-by: Cursor <cursoragent@cursor.com>
jesuswr
marked this pull request as ready for review
September 14, 2026 15:28
|
Pinging @elastic/kibana-core (Team:Core) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #284558
When the OTel collector is down, the OTel appender gives up too fast and drops logs:
This PR makes both configurable so short collector outages don't lose logs:
maxElapsedTime(serverless default:2m): how long a failed export keeps retrying with exponential backoff before the batch is dropped. Implemented in a newRetryingLogRecordExporterthat wraps the OTLP exporter. Only transient errors are retried (network errors, HTTP 429/502/503/504, gRPCDEADLINE_EXCEEDED/UNAVAILABLE). Things like auth failures or bad requests fail immediately, as before.maxQueueSize(serverless default:15000): how many log records the batch processor buffers in memory. When full, new records are dropped and the SDK logs a warning with the count. Minimum is 512 so it never goes below the SDK's batch size.Both settings are only exposed in serverless YAML config. Internal plugins can also set them through the runtime config.
About the defaults
Both defaults come from the example in the issue. To sanity-check
15000, we measured real Kibana log events: typical records are ~1–2KB, error records with stack traces are ~2–4KB, and the largest ones observed are ~10KB. So a full queue is ~30MB in the typical case, and can be higher during error storms (which is when the queue actually fills). If we'd rather bound the worst case, we can lower the default — it's a one-line change.Testing
node scripts/jest src/core/packages/logging/server-internal/src/appenders/otel)node scripts/jest_integration src/core/server/integration_tests/logging/otel)node scripts/type_checkon the touched projects) and lint pass