-
Notifications
You must be signed in to change notification settings - Fork 227
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
fix: ensure correct run context for '@elastic/elasticsearch' instrumentation #2550
Conversation
…ntation This is a re-write of the @elastic/elasticsearch instrumentation that stops using the ES client observability events https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/observability.html and switches to patching Transport#request() instead. This is necessary to be able to bind that `request()` invocation to the RunContext for the Span we've created; without using `apm.startSpan(...)`, which bleeds the RunContext out to user code. (Patching Transport#request() is what the legacy 'elasticsearch' instrumentation is also doing.) Refs: #2430
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
run module tests for @elastic/elasticsearch,@elastic/elasticsearch-canary,elasticsearch |
…ater elastic/elasticsearch-js@76659b6 special-cased 'sort' so it is always passed as a query param in the ES request.
- No longer need to adjust tests around elasticsearch-js issue 151 because we are no longer using the diagnostics events where that happened. - Cope with <v7.7.0 where the instrumentation would create *two* spans for Promise-usage of client requests.
run module tests for @elastic/elasticsearch,@elastic/elasticsearch-canary,elasticsearch |
@@ -367,7 +367,7 @@ elasticsearch: | |||
commands: node test/instrumentation/modules/@elastic/elasticsearch.test.js | |||
'@elastic/elasticsearch-canary': | |||
name: '@elastic/elasticsearch-canary' | |||
versions: '^8.0.0-canary.35' | |||
versions: '>=8.0.0-canary.36 || >=8.1.0-canary.2' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEW NOTE: Kibana's HEAD is using 8.1.0-canary.2
now. I had to drop at least 8.0.0-canary.35
because our tests depend on elastic/elasticsearch-js@76659b6 which special-cased handling of the "sort" param to client commands such that it is always passed as a query param to ES.
parts.push(JSON.stringify(body)) | ||
} | ||
} catch {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEW NOTE: try/catch around these in case there is a surprise circular ref or something. I'll be opening a separate ticket to improve our instrumentation patching so that we can capture the body and querystring as serialized by the client instead of having to do it (again) in the agent.
@@ -542,17 +541,11 @@ ${body.map(JSON.stringify).join('\n')} | |||
|
|||
const err = data.errors | |||
.filter((e) => e.exception.type === 'RequestAbortedError')[0] | |||
if (semver.satisfies(esVersion, '7.14.x')) { | |||
// https://github.com/elastic/elasticsearch-js/issues/1517 was fixed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEW NOTE: This issue was only relevant when using the diagnostics events from the ES client. Given that the instrumentation re-write is no longer using those events, we no longer need to have the tests workaround the issue.
// Remove leading ES span and HTTP span from product check. | ||
data.spans = data.spans.slice(2) | ||
// Remove the product check spans for subsequent assertions. | ||
data.spans = data.spans.slice(0, 1).concat(data.spans.slice(3)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEW NOTE: The order of product-check spans has changed due to the change in the implementation of the instrumentation. We create a Span on Transport#request()
now, rather than later when the "request" diagnostic event is sent. That means that the first Span is the one we want to keep.
- ES span for the actual client command (want to keep this one)
- ES span for the product check
- HTTP span for the product check
- HTTP span for the actual client command (want to keep this one)
@@ -125,7 +125,7 @@ if (semver.satisfies(pkg.version, '>= 13')) { | |||
} | |||
] | |||
|
|||
var statement = body.map(JSON.stringify).join('\n') | |||
var statement = body.map(JSON.stringify).join('\n') + '\n' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEW NOTE: This is for the slight change in setElasticsearchDbContext()
's handling of the Array.isArray(body)
case to match how this is serialized by the @elastic/elasticsearch
client.
…t out to user code
run module tests for @elastic/elasticsearch,@elastic/elasticsearch-canary,elasticsearch |
run module tests for @elastic/elasticsearch,@elastic/elasticsearch-canary,elasticsearch |
…service container was not being setup for its test run; we didn't see this in CI before because the Jenkins TAV config doesn't have the canary module
run module tests for @elastic/elasticsearch,@elastic/elasticsearch-canary,elasticsearch |
In elastic#2550 this module was rewritten to not be primarily based on the ES client "diagnostic" events for instrumentation. That change should have also removed this part of the top-comment. Refs: elastic#2550
This is a re-write of the @elastic/elasticsearch instrumentation that
stops using the ES client observability events
https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/observability.html
and switches to patching Transport#request() instead. This is necessary
to be able to bind that
request()
invocation to the RunContext for theSpan we've created; without using
apm.startSpan(...)
, which bleeds theRunContext out to user code. (Patching Transport#request() is what the
legacy 'elasticsearch' instrumentation is also doing.)
Refs: #2430
Checklist