feat(opentelemetry-sampler-aws-xray): Add Rules Caching and Rules Matching Logic #2824
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2824 +/- ##
=======================================
Coverage 89.64% 89.64%
=======================================
Files 184 184
Lines 9032 9032
Branches 1852 1852
=======================================
Hits 8097 8097
Misses 935 935 🚀 New features to boost your workflow:
|
|
cc @lukeina2z for review who is familiar with Sampling. Currently everything is implemented except for Updating Sampling Targets and the Rate Limiting (Reservoir) Sampler. |
| } | ||
|
|
||
| public toString(): string { | ||
| return 'FallbackSampler{fallback sampling with sampling config of 1 req/sec and 5% of additional requests'; |
There was a problem hiding this comment.
nit: what does '{' mean in the string?
There was a problem hiding this comment.
Oops, I forgot to the } at the end of the string. This method intends to return a description of this sampler, in the format of FallbackSampler{ <description> }.
| } | ||
|
|
||
| public updateRules(newRuleAppliers: SamplingRuleApplier[]): void { | ||
| const oldRuleAppliersMap: { [key: string]: SamplingRuleApplier } = {}; |
There was a problem hiding this comment.
nit: You could use a Map<string, SamplingRuleApplier> instead of a plain object here for better perf.
There was a problem hiding this comment.
Thanks! I Incorporated your suggestion.
| attributes: Attributes | ||
| ): SamplingRuleApplier | undefined { | ||
| return this.ruleAppliers.find( | ||
| rule => |
There was a problem hiding this comment.
Could this, in some cases, find the default rule before a higher priority rule? Will this matter?
There was a problem hiding this comment.
This use of find() here relies on the this.ruleAppliers list being always sorted by priority (ascending integers), where the default rule is always hardcoded to be the last priority by AWS X-Ray. This sorting is assumed because it is sorted here whenever the Sampling rules are updated. This assumption is important, I've added a comment.
| // If scheme is not present, assume it's bad instrumentation and ignore. | ||
| if (schemeEndIndex > -1) { | ||
| // urlparse("scheme://netloc/path;parameters?query#fragment") | ||
| httpTarget = new URL(httpUrl).pathname; |
There was a problem hiding this comment.
Ensure that this will never receive a malformed httpUrl as it will throw if it does.
There was a problem hiding this comment.
Nice catch, I chose to rely on a try...catch to handle this.
Which problem is this PR solving?
Short description of the changes
This PR is a followup to #2750
RuleCacheSamplingRuleAppliers, ordered by rule priority then rule name. Each Rule Applier corresponds to the Sampling Rule from GetSamplingRules. Each call to GetSamplingRules will only update theRules that have changed properties, to preserve the state of unchanged rules. This means when Reservoir and Statistics are implemented (later) in theRules, they will persist for unchanged rules.{ResourceAttributes,SpanAttributes}) that has highest priority.SamplingRuleApplierto perform Fixed Rate Sampling, and to include a method to apply matching logic against a set of {ResourceAttributes,SpanAttributes} by using the wild card and attribute matching from UtilsFallbackSamplerX-Ray Remote Samplerto depend on the SamplingRuleApplier fromRuleCacheand the FallBack Sampler to performshouldSample