-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Stop Kibana from generating unique X-Opaque-ID values when not received from the client. #123737
Comments
Pinging @elastic/kibana-core (Team:Core) |
A draft PR doing most of the technical changes is available here: #120124 We still need a decision regarding
We may want to perform load testing to determine the impact of the We can probably tweak the load tests from elastic/kibana-load-testing#221 to check the perf impact of |
@dmlemeshko I know you've been looking into perf impacts of enabling APM, would you be able to help us assess the impact of this particular option? |
@lukeelmers Please just open an issue with details and will try to do it asap. |
@dmlemeshko I opened elastic/kibana-load-testing#245. Please tell me if you need more information |
@dmlemeshko did you find an opportunity to take a look at elastic/kibana-load-testing#245? |
I performed the benchmarking and posted the results here: #129585 (comment) TLDR: there is a significant difference between APM being fully disabled and being enabled in So I guess we're back to the initial plan to simply document that features relying on @lukeelmers wdyt? |
Since I was subscribed to this issue: I'll chime in on behalf of Platform Security and say I am fine with this 👍 |
++ Agreed, I think this is acceptable given these findings, as long as Platform Security is comfortable with it. |
We've been historically generating unique
x-opaque-id
values for each Kibana request, and transmitting those values to elasticsearch every time a request is performed using a scoped client.This was done with the assumption that this value had no semantics or no functional usage in elasticsearch. However, this assumption was wrong, as this opaqueId value is now used for some features such as deprecation logs deduplication.
We need to stop generating values for
x-opaque-id
/ (also exposed asrequest.id
) when the client initiating the request against Kibana does not provide one, and not propagate the value to elasticsearch.Now that ES has support for the
traceparent
header (elastic/elasticsearch#74210), we can use thetrace.id
value as correlation id for Kibana features that require so.Note that if this
x-opaque-id
/request.id
value is supposed to be mostly internal to core, it's currently used by the audit logging as their correlation value between Kibana and Elasticsearch audit logs. We will need to adapt Kibana's audit logging to stop overriding trace.id with request.id and update their documentation to reflect the fact that the correlation value will now betrace.id
Also, for this
traceparent
header to be sent to elasticsearch, the APM agent needs to be enabled, as least incontextPropagationOnly
mode (which is the default configuration). We need to figure out if this limitation is acceptable and if documenting it is good enough, or if we may want to consider this feature of the APM agent as an implementation detail and stop allowing customer to disable it.More context in the original issue: #120124
cc @elastic/kibana-security
The text was updated successfully, but these errors were encountered: