Add semantic conventions for Elasticsearch client instrumentation

[estolfo]

This PR originated as a PR in the opentelemetry-specification repo.
The outstanding discussion point from that PR was regarding the path forward for the existing Elasticsearch client instrumentations:

• .NET: No concerns about updating their instrumentation to adopt these semantic conventions
• Python: No concerns about updating their instrumentation to adopt these semantic conventions
• Java: request to understand the complexity of updating the instrumentation by opening a PR with the changes

We are in the process of figuring out the path forward for the Java instrumentation and I'll update here when we have a plan.

Two instrumentations in progress that will use these semantic conventions:

• PHP
• Ruby

[estolfo]

Hi @lmolkova, we've discussed what changes to make based on your comments/questions.

We agree it makes sense to have url.full instead of the url.path and url.query. We think it's still important to have the components extracted out, so we'll have doc_id, target, url.full and the span name containing the path pattern with placeholders that will together provide a complete set of information on the api queried and with what data.
We've added a note that the server address and port are recommended.

We are also assuming from the spec that there will also be an http span.

Lastly, we've changed the db.statement to capture the request body for search-type queries. The list of Search APIs can be found here.

A config option could also be used that allows users to opt-in for capturing bodies of every request.

[joaopgrassi]

It would be great to get some insights on what is the intended span structure such conventions want to achieve. The initial paragraph about an HTTP span already existing is a bit unclear if an additional span for Elasticsearch should always be there, or attributes should be added to the underlying http span.

[lmolkova]

@estolfo thank you for addressing my comments! Please also add a changelog entry.

[estolfo]

@lmolkova and @joaopgrassi I've updated the span name and attributes after a discussion with some more people internally.
There are two main changes:

• span name is the endpoint id of the request (the name field here, ex: search), rather than the http request method and request template (ex GET /{target}/_doc/{id}) . The Elasticsearch clients team said people would more likely want to identify ES requests by the endpoint id and that the request template would be less natural for them to see as a request identifier. We also have the http method anyway in the span attributes so we don't need to repeat it in the span name.
• the dynamic parts of the url path are set at span attributes like they are for http headers, as db.elasticsearch.path_parts.<key>

What do you think?

[joaopgrassi]

Given you are the subject-matter expert here I think the span name change makes sense (makes more sense to customers). But the path_parts change I'm not sure. I left a common with my concerns there

[joaopgrassi]

@open-telemetry/specs-semconv-maintainers could you please take a look? Thanks!

[jsuereth]

Generally looks good to me, but have some concerns around the implications of sensitive data handling.

[joaopgrassi]

Depending when this merges, it might be affected by #143

[estolfo]

I think @carlosalberto said in the SIG last night that he'd approve it and then we can merge.

[Mpdreamz]

LGTM