For applications on Linux systems that use OpenTelemetry (OTel) instrumentation, the connector adds query and connection spans to the trace generated by application code and forwards the current OpenTelemetry context to the server. OpenTelemetry tracing was introduced in the Connector/ODBC 8.1.0 release.
OTel context forwarding works only with MySQL Enterprise Edition, a commercial product. To learn more about commercial products, see https://www.mysql.com/products/.
By default, the connector forwards the context only when an instrumented application installs the required OpenTelemetry SDK libraries and configures the trace exporter to send trace data to some destination. If the application code does not use instrumentation, then the legacy connector does not use it either.
Connector/ODBC supports a connection property option,
OPENTELEMETRY
, which has these values:
PREFERRED
: Default. Use instrumentation in the connection if the required OpenTelemetry instrumentation is available. Otherwise, permit the connection to operate without any OpenTelemetry instrumentation.-
DISABLED
: The connector does not create OpenTelemetry spans or forward the OpenTelemetry context to the server.Setting to boolean
false
behaves the same asDISABLED
.
When you build code that links to Connector/ODBC and uses OTel instrumentation, the additional spans generated by the connector appear in the traces generated by your code. Spans generated by the connector are sent to the same destination (trace exporter) where other spans generated by the user code are sent as configured by user code. It is not possible to send spans generated by the connector to any other destination.
This implementation is distinct from the implementation
provided through the MySQL client library (or the related
telemetry_client
client-side plugin).
OTel instrumentation in the ODBC driver only functions if the
application is built with the -rdynamic
compiler option so that symbols defined in user code are
externally visible. Without this, the OTel context is not
forwarded to the server (as the driver has no way of getting
the current OTel context) and the spans generated by the ODBC
driver will be not sent to the destination specified in the
application (they will be discarded).