Improve observability

[delvedor]

With this pr, we add support for the request id. With it, it will be easier correlate clients events and in the future enhance the client observability.

It can be fully customized in the configuration options (as well as in the child clients) and can be overridden with the specific request options.

@watson @Qard: can this be useful for you? What can I do to improve the client observability for Elastic APM?

Example:

const { Client } = require('@elastic/elasticsearch')
const client = new Client({
  node: 'http://localhost:9200'
  // generateRequestId: function () { ... }
})

client.on('request', (err, { meta }) => {
  console.log(meta.request.id)
})

client.on('response', (err, { meta }) => {
  console.log(meta.request.id)
})

client.info(console.log)
client.info({}, { id: 'custom' }, console.log)

/cc @tylersmalley @epixa @spalger

[Qard]

It seems to be in pretty good shape from APM perspective. With the request and response events we can capture the start and end of a request easily, and we have the metadata to capture the path, body, host, etc.

Thanks for the notice. :)

[delvedor]

I'm thinking if it is worth to add a context object instead, which will contain the request id and any more data you might be interested in.

Eg:

const { Client } = require('@elastic/elasticsearch')
const client = new Client({
  node: 'http://localhost:9200'
})

client.on('request', (err, { meta }) => {
  console.log(meta.request.context) // { id: 0, winter: 'is coming' }
  meta.request.context.star = 'wars'
})

client.on('response', (err, { meta }) => {
  console.log(meta.request.context) // { id: 0, winter: 'is coming', star: 'wars' }
})

client.info({}, { context: { winter: 'is coming' } }, console.log)

[delvedor]

Yes, if you don't do anything, context will be { id: 'some-id' }, and the id will be generated by generateRequestId (unless you override it).

[delvedor]

I've done some more changes which should improve the observability:

• event client instance now has a name (which can be configured), this is very useful when working with child clients.
• In every request, you can provide a custom context object that you can access later.
• Now you can access request id and client name also in the resurrect event.
• observability doc

In code:

const { Client } = require('@elastic/elasticsearch')
const client = new Client({
  node: 'http://localhost:9200',
  name: 'cluster-abc'
})

client.on('request', (err, { meta }) => {
  const { name, context, request } = meta
  console.log(name, context, request.id)
})

client.info({}, { context: { winter: 'is coming' }, id: 'custom-id' }, console.log)

[tylersmalley]

👍 this is great.

[tylersmalley]

LGTM - just minor nitpicks to the docs. This gives me a lot of ideas for Kibana!

[Conky5]

Jenkins retest this please

[spalger]

A couple lingering questions, but LGTM

[spalger]

LGTM, thanks!

[delvedor]

Jenkins retest this please