Wired Up Reporting to Shim#2689
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2689 +/- ##
============================================
+ Coverage 73.28% 73.46% +0.17%
Complexity 106 106
============================================
Files 721 721
Lines 33372 33441 +69
Branches 2910 2915 +5
============================================
+ Hits 24457 24566 +109
+ Misses 7582 7535 -47
- Partials 1333 1340 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
35d5751 to
c4e3547
Compare
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
94e338e to
5b2d393
Compare
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
...ture/transformationShim/src/main/java/org/opensearch/migrations/transform/shim/ShimMain.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
a8588ff to
56f2fc1
Compare
| Map<String, Object> responseRequestMap = hasCursorMark ? targetRequestMap : requestMap; | ||
| futures.put(name, dispatchToTarget(target, targetRequestMap, responseRequestMap, dispatchCtx)); | ||
|
|
||
| collectTransformData(target, name, targetRequestMap, |
There was a problem hiding this comment.
How is metricsMap not empty at this point? I would expect the responses are async and we have to wait on futures before the responses are populated
There was a problem hiding this comment.
The metrics are coming from the request translations. For example, if a request translation notices some limitation, (like offsets not being supported by OpenSearch inside aggregation buckets) the transform will emit a metric. So the metrics will be available as soon as the request transform is run and we come back from GraalVM.
There was a problem hiding this comment.
The pr overview here says
so every dual-target request automatically produces a ValidationDocument
with hit-count drift, latency delta, and optional request/response bodies.
Is this accurate?
There was a problem hiding this comment.
That is correct. (Obviously the user must pass --reportingConfig to enable this.) The list is not exhaustive. Do you see an accuracy issue here?
Signed-off-by: Andre Kurait <akurait@amazon.com>
…ures Signed-off-by: Andre Kurait <akurait@amazon.com>
Signed-off-by: Akshay Zade <zadaksha@amazon.com>
827f375 to
91de63e
Compare
Description
Wires the existing
MetricsReceiverandReportingSinkintoMultiTargetRoutingHandlerso every dual-target request automatically produces aValidationDocumentwith hit-count drift, latency delta, and optional request/response bodies. Reporting is enabled via a--reportingConfigJSON CLI flag and is wired into the dev sandbox dual-target shims. All new constructor params default to null for backward compatibility.Testing
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.