Adaptive Sampling Support#576
Merged
majanjua-amzn merged 2 commits intomainfrom Jan 27, 2026
Merged
Conversation
majanjua-amzn
added
bug
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
from
573ecdf to
11a96d7
Compare
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
8 times, most recently
from
d9a38a2 to
a39c57b
Compare
wangzlei
pushed a commit
that referenced
this pull request
Jan 14, 2026
### Background Recently, a new field was added to the X-Ray GetSamplingRules API that was not accounted for in the AWS X-Ray Remote Sampler implementation done in ADOT Python. As a result, enabling this new field would cause a failure and cease the parsing of any other rules in a given API response. Example: Received 10 rules from the API, third of which has the SamplingRateBoost field. The SDK will successfully parse the first two, fail on the third, then stop there. As such, the SDK will only have 2/10 of the sampling rules and will not be able to effectively make sampling decisions based on the sampling rules set by the user. Any unmatched spans will use the _FallbackSampler. ### Changes - Add usage of `kwargs` in X-Ray sampling API related objects, e.g. SamplingRule, SamplingTarget, etc. - Add unit tests proving additional fields do not cause errors. ### Testing - Unit tests - Tested in depth as part of #576, which this change was a part of but is now separated out to get it in more quickly By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
ezhang6811
pushed a commit
to ezhang6811/aws-otel-python-instrumentation
that referenced
this pull request
Jan 15, 2026
Recently, a new field was added to the X-Ray GetSamplingRules API that was not accounted for in the AWS X-Ray Remote Sampler implementation done in ADOT Python. As a result, enabling this new field would cause a failure and cease the parsing of any other rules in a given API response. Example: Received 10 rules from the API, third of which has the SamplingRateBoost field. The SDK will successfully parse the first two, fail on the third, then stop there. As such, the SDK will only have 2/10 of the sampling rules and will not be able to effectively make sampling decisions based on the sampling rules set by the user. Any unmatched spans will use the _FallbackSampler. - Add usage of `kwargs` in X-Ray sampling API related objects, e.g. SamplingRule, SamplingTarget, etc. - Add unit tests proving additional fields do not cause errors. - Unit tests - Tested in depth as part of aws-observability#576, which this change was a part of but is now separated out to get it in more quickly By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
from
a39c57b to
df9a816
Compare
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
4 times, most recently
from
9d2eba7 to
930a1ec
Compare
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
from
cdf83b8 to
a6d3d22
Compare
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
2 times, most recently
from
6bb1e54 to
cc9c0b8
Compare
majanjua-amzn
force-pushed
the
adaptive-sampling
branch
from
1ba476e to
45a83e4
Compare
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
2 participants
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.
Background
AWS X-Ray sampling rules now support an adaptive sampling configurations, and as part of that effort the ADOT SDKs must be updated to support the ingestion of the new fields and appropriate functional changes to support [1] boosting sampling rate based on detected anomalies and [2] detect/capture anomalies based on a configuration local to the SDK.
The same changes have been made for the ADOT Java SDK here in the upstream OTel Contrib repo: open-telemetry/opentelemetry-java-contrib#2147
Overall, the goal of this PR is to meet the same needs as the one in ADOT Java with some additional improvements:
aws.xray.adaptive_sampling_configuredto identify spans that were generated from an SDK with a local adaptive sampling configurationChanges
Testing
errorCodeRegex: "^500|501$"where service C generates a 500 response: Appropriately detects and captures anomalies + responds to boost sent by servererrorCodeRegex: "^500|501$", operations: ["GET /status"], where service C generates a 500 response from/status/c/500: Appropriately detects and captures anomalies + responds to boost sent by servererrorCodeRegex: "^500|501$", highLatencyMs: 2000, where service C generates a 3 second span with 200 or 500 response: Appropriately not treated as an anomaly when 200, and as an anomaly when 500highLatencyMs: 2000, where service C generates a 3 second span with 200 response: Appropriately treated as an anomalyLinks
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.