enable execution_context by default

[mshustov]

Summary

Closes #102706
Since the last time @dmlemeshko conducted load testing, Kibana has made several changes that have a significant impact on execution_context performance: upgrade nodejs to v16 and enable async_hooks by default

So the new testing is necessary. We want to enableexecution_context by default to provide the best UX with Kibana query source propagation to the Elasticsearch server.

Benchmarks

I use the standard DemoJourney scenario from https://github.com/elastic/kibana-load-testing
95pt of the response time shows the difference within the statistical error.
main branch

PR brach

Plugin API changes

It might be hard in the distributed environment to understand what Kibana entity initiated a request to the Elasticsearch server. To overcome this problem we introduced a content of execution_context to attach domain-specific metadata to every request. execution_context propagates specified metadata from the Kibana browser app or Kibana server to the Elasticsearch server via x-opaque-id header emitted to the Elasticsearch slow logs. For further details check a troubleshooting guide here.

Execution context has the following interface:

export type KibanaExecutionContext = {
  /** Kibana application initated an operation.*/
  readonly type: string; // 'visualization' | 'actions' | 'server' | ..;
  /** public name of a user-facing feature */
  readonly name: string; // 'TSVB' | 'Lens' |  'action_execution' | ..;
  /** unique value to identify the source */
  readonly id: string;
  /** human readable description. For example, a vis title, action name */
  readonly description: string;
  /** in browser - url to navigate to a current page, on server - endpoint path, for task: task SO url */
  readonly url?: string;
  /** a context that spawned the current context. */
  parent?: KibanaExecutionContext;
};

Kibana plugin can attach request specific metadata to an outbound HTTP request on the client side as

const parentContext = {
  type: 'my-app',
  name: 'my-plugin-ui-feature',
  id: '42',
  description: 'Retrieve number of X for Y',
};
async function getData() {
  return await http.get('...', { headers: new ExecutionContextContainer(parentContext).toHeader() });

and on the server-side you need to wrap any async operation with withContext helper:

 const chainB = service.withContext({
  type: 'my-app-server',
  name: 'my-plugin-server-feature',
  id: '43',
  description: 'Query Z',
  },
 async () => {
   return  await esClient.search(...);
 }
);

Then, in Elasticsearch slow logs you might find a hint that a request was initiated by my-plugin-ui-feature feature of my-app application and proxied through my-plugin-server-feature features of my-app-server app:

x-opaque-id: ${requestId};kibana:my-app:my-plugin-ui-feature:42;my-app-server:my-plugin-server-feature:42

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Overhead of execution context tracking might be higher than anticipated.	Low	High	We will keep an eye on the result of performance testing conducted on CI to make sure the PR doesn't affect performance. Should we spot a problem starting from the date of the merge, we would revert the PR.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[mshustov]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 554b2fe
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💔 Build #9903 failed 46fe0b7

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[afharo]

LGTM! 🎉