-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
span composite count must be > 1 #3265
Comments
By looking through the code, this seems to only be possible by a very specific race-condition.
Now the following things need to happen:
I think what we could do is guard the compression process with a I'd love to have some input from @elastic/apm-agent-java (and maybe @felixbarny and @eyalkoren as original authors) here. Is it known (and accepted) that the span-compression is prone to lost-update race conditions? As a bandaid fix to prevent spans from being rejected by the APM-server I'll add a guard to the serialization logic so that we don't report spans with |
Span compression is purely for improved UI and I don't think it's worth a lot of effort to handle edge cases in high contention cases other than to just drop the odd compression rather than add load. So I think the proposed band aid is sufficient |
Describe the bug
From the APM Agents spec (https://github.com/elastic/apm/blob/main/specs/agents/handling-huge-traces/tracing-spans-compress.md?plain=1#L137-L138):
It looks like the java agent is reporting composite spans with a lower count. The following error was observed in ecs logs:
validation error: span: composite: 'count': validation rule 'min(2)' violated
Steps to reproduce
I don't have those unfortunately :(
This is part of the ops KPI review
Expected behavior
Composite count must be > 1
Debug logs
validation error: span: composite: 'count': validation rule 'min(2)' violated
The text was updated successfully, but these errors were encountered: