What are you trying to achieve?
There is a detailed specification and semantic conventions provided for AWS technologies, for example, for DynamoDB-related spans here and there isn't one for Elasticsearch.
In the last week, I implemented instrumentation of the Elasticsearch Ruby client that I will soon open as a pull request to the OpenTelemetry Ruby project. I found that the existing Elasticsearch client instrumentations I referenced (mainly the Python and Java implementations) differed from each other in terms of what span attributes were set, what values were used for the attributes and what custom attributes were set. For example, the Python implementation sets the request body as the db.statement while the Java implementation only sets the request method and url as db.statement. The Python implementation also sets custom elasticsearch span attributes.
I also know that we have someone from Elastic working on a Elasticsearch PHP client instrumentation to propose to the PHP OpenTelemetry project. That effort would benefit from a detailed spec as well.
I think having a similar set of semantic conventions for Elasticsearch as are provided for AWS technologies would be valuable so that we don't have more instrumentations of Elasticsearch clients that differ from each other.
Additional context.
One concern when setting Elasticsearch span attributes is cardinality when the url path is used. Some endpoints contain index names and/or document ids that can greatly increase the cardinality of the attribute values that are set using the url path. The specification will propose rules as are listed here for how to refer to a given API endpoint.
If adding a specification for Elasticsearch client instrumentation is approved, I'll open a pull request with proposed span attributes to set and their values.
What are you trying to achieve?
There is a detailed specification and semantic conventions provided for AWS technologies, for example, for DynamoDB-related spans here and there isn't one for Elasticsearch.
In the last week, I implemented instrumentation of the Elasticsearch Ruby client that I will soon open as a pull request to the OpenTelemetry Ruby project. I found that the existing Elasticsearch client instrumentations I referenced (mainly the Python and Java implementations) differed from each other in terms of what span attributes were set, what values were used for the attributes and what custom attributes were set. For example, the Python implementation sets the request body as the
db.statementwhile the Java implementation only sets the request method and url asdb.statement. The Python implementation also sets custom elasticsearch span attributes.I also know that we have someone from Elastic working on a Elasticsearch PHP client instrumentation to propose to the PHP OpenTelemetry project. That effort would benefit from a detailed spec as well.
I think having a similar set of semantic conventions for Elasticsearch as are provided for AWS technologies would be valuable so that we don't have more instrumentations of Elasticsearch clients that differ from each other.
Additional context.
One concern when setting Elasticsearch span attributes is cardinality when the url path is used. Some endpoints contain index names and/or document ids that can greatly increase the cardinality of the attribute values that are set using the url path. The specification will propose rules as are listed here for how to refer to a given API endpoint.
If adding a specification for Elasticsearch client instrumentation is approved, I'll open a pull request with proposed span attributes to set and their values.