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.
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
No longer use generated IDs for
X-Opaque-ID
/requestId
#123197No longer use generated IDs for
X-Opaque-ID
/requestId
#123197Changes from all commits
37bc63c
468efa6
9734eb9
bc5aa3d
b288f90
8067e4f
5e9efcf
fd2e8a7
3256a6c
c10bd2d
f2d34a0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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.
(This is correlated with the change in
src/core/server/elasticsearch/client/cluster_client.ts
)ATM we kinda have an inconsistency between when EC is enabled or not, as when EC is enabled, the
x-opaque-id
value will be coming fromEC.getAsHeader
, and when it's not, the value is generated withinClusterClient.getScopedHeaders
ATM (with the PR's current change), the value matrix looks like:
x-opaque-id
sent to ES'${opaqueId};kibana:${executionContext}'
'${opaqueId}'
'unknownId;kibana:${executionContext}'
'unknownId'
'${opaqueId}'
undefined
I got a few questions here:
unknownId
default value foropaqueId
acceptable?kibana
as the default value, but then, in case of populated execution context, the value would look likekibana;kibana:${executionContext}
. Are we fine with this format? Do we just want to usekibana:${executionContext}
in that case instead?ClusterClient.getScopedHeaders
. ATM whenrequest.opaqueId
is not present, we're not sending anyx-opaque-id
header to ES. Do we want to change that to sendkibana
(or any constant value we agreed on from the previous point) instead?x-opaque-id
header and havegetAsHeader
always return a value even when disabledrequestIdStore
to always be populated even when EC is disabled, which could be a performance issue as the whole purpose of allowing to disable the EC was for performances reasons@mshustov @lukeelmers what do you think about this?
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.
Worth noting, ES doesn't parse
x-opaque-id
value, so we can use any format. I usedkibana
static value to simplify parsing when an incoming request containsx-opaque-id
. If you find it easier to usekibana;${executionContext}
, we can change the format.@pgomulka what is better for the depreciation service of Elasticsearch?
I didn't put this logic in the EC service to have a proper separation of concerns. The fact we put
execution_context
inx-opaque-id
header of outbound requests is an implementation detail. When thebuggage
header is available, we will use it for context propagation. Having said that, I'd rather keep this logic on theelasticsearch service
level. But we can refactor it a bit.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.
either way is good. As long as it is constant (or from a finite set). If Kibana wants to send a constant
x-opaque-id-from-kibana
it would help identifying its requestsThere 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.
Let's not overcomplicate the PR for no good reasons. The current format is good enough to address #120124, let's not change it for now. We'll reevaluate when we'll use the
baggage
header anyway.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.
@elastic/kibana-security
request.id
was renamed torequest.opaqueId
, but is now optional, as we're no longer generating a value when not provided by the client / when the configuration forbid its usage.Is this change fine, or should we fallback to
request.uuid
whenrequest.opaqueId
is empty?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.
JFYI: Kibana sets tracing fields starting from #118466 The value from
meta
override them (sorry, I need to update the test suite name 😅 )kibana/src/core/server/logging/layouts/json_layout.test.ts
Line 331 in b288f90
maybe audit logging should rely on the
trace
field supplied by the Kibana server and not overwrite them?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.
#118466 was merged on 8.1 only, and not backported though, right?
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.
yes, it wasn't. because it's not a bug fix
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.
I responded to the linked issue in #120124 (comment).
I'm not on board with this change in general as it hamstrings auditing functionality. If we have to go through with this though, we at least need the ability to correlate audit records within the Kibana audit log which originate from the same request. In that case it would be better to fall back to
request.uuid
.