You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem including expected versus actual behavior:
When starting our opbeans Java application with OpenTelemetry instrumentation agent, the calls to the database are instrumented.
When the application starts, there are a few calls to the database to insert test data.
Those calls to database are captured as OTel spans and sent to Elastic APM.
The issue here is that those spans are a CLIENT spans, and such spans are not expected to create transactions.
With Elastic APM Agents, the lack of a transaction to "wrap" those database calls make them not captured.
Steps to reproduce:
We assume here that a local APM Server is running on the local system and listening to 0.0.0.0:8200 to allow docker images to communicate with it. Re-building once the opbeans java app docker image is required as not-yet-released changes are required.
This is intentional, and happening because there's no parent ID: all trace roots are "transactions".
I'm not convinced we should use the CLIENT span kind to automatically drop these. What about INTERNAL spans (the default span kind)? Should we drop those?
I see, heuristics on span kind still remain heuristics, thus prone to errors.
Would open-telemetry/oteps#182 allow to properly solve this in an elegant way without heuristics on APM server ?
APM Server version (
apm-server version
): 8.0.0Description of the problem including expected versus actual behavior:
When starting our opbeans Java application with OpenTelemetry instrumentation agent, the calls to the database are instrumented.
When the application starts, there are a few calls to the database to insert test data.
Those calls to database are captured as OTel spans and sent to Elastic APM.
The issue here is that those spans are a
CLIENT
spans, and such spans are not expected to create transactions.With Elastic APM Agents, the lack of a transaction to "wrap" those database calls make them not captured.
Steps to reproduce:
We assume here that a local APM Server is running on the local system and listening to
0.0.0.0:8200
to allow docker images to communicate with it. Re-building once the opbeans java app docker image is required as not-yet-released changes are required.The spans are visible in the Traces view in Kibana:
And they are stored as transactions in Elasticsearch:
We can find them with the following KQL query :
processor.event :"transaction" and labels.db_name:*
.Sample document
The text was updated successfully, but these errors were encountered: