-
Notifications
You must be signed in to change notification settings - Fork 175
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
Add semantic conventions for Elasticsearch client instrumentation #706
Comments
Hi all, can you tell me if I should work on a spec and open a PR? |
hi @estolfo! I think this would be very valuable since OpenTelemetry Elasticsearch instrumentation already exists across multiple languages. I suspect you can get enough reviewers of your spec PR from those language groups in order to get it through the specification process. |
Hi @trask thanks for your response. I'll get started on a spec and submit a PR soon then. |
yes indeed! |
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 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.
The text was updated successfully, but these errors were encountered: