feat: create span for mysql2 execute

[xuan-cao-swi]

Description

Adding a span for the mysql2 execute function is similar to the pg EXEC_PREPARED_ISH_METHODS.

When using prepared statements with ActiveRecord, the first execution of a query will create a prepare span, which can log the query execution. However, re-execution will not trigger the prepare function; it will trigger the execute function directly. Since we currently don’t create a span for the execute function, I’d like to propose adding a span for the execute function.

See prepared statement execution log from mysql server:

# first time call the query
2024-11-01T19:35:33.716687Z	   12 Prepare	SELECT `customers`.* FROM `customers` WHERE `customers`.`contactLastName` = ? LIMIT ?
2024-11-01T19:35:33.716952Z	   12 Execute	SELECT `customers`.* FROM `customers` WHERE `customers`.`contactLastName` = 'Schmitt' LIMIT 1

# second time call the query
2024-11-01T19:35:38.256820Z	   12 Execute	SELECT `customers`.* FROM `customers` WHERE `customers`.`contactLastName` = 'Schmitt' LIMIT 1

# third time call the query with different binding value
2024-11-01T19:35:46.300242Z	   12 Execute	SELECT `customers`.* FROM `customers` WHERE `customers`.`contactLastName` = 'Snow' LIMIT 1

Even though there is no valuable information except the binding value for the prepared statement, it is useful for monitoring the MySQL query execution duration.

Sample span data:

otel-collector     | InstrumentationScope OpenTelemetry::Instrumentation::Mysql2 0.27.2
otel-collector     | Span #0
otel-collector     |     Trace ID       : e93599e8a955311184c69c52769adc26
otel-collector     |     Parent ID      : 949f6bc157ecbb9a
otel-collector     |     ID             : ef2baa0ac9121262
otel-collector     |     Name           : execute
otel-collector     |     Kind           : Client
otel-collector     |     TraceState     : sw=0000000000000000-01
otel-collector     |     Start time     : 2024-11-01 19:35:46.300091427 +0000 UTC
otel-collector     |     End time       : 2024-11-01 19:35:46.301052177 +0000 UTC
otel-collector     |     Status code    : Unset
otel-collector     |     Status message : 
otel-collector     | Attributes:
otel-collector     |      -> args: Str(["Snow", 1])
otel-collector     |      -> kwargs: Str({})

[arielvalentin]

I do agree that we should amend all attributes without using explicit mappings for semantic conventions especially if it opens up a risk to exposing sensitive data.

E.g. auth token or password would be exposed through telemetry collection, with a safeguards to remove them.

I do realize we allow this to happen today with our existing include statement but I am leaning more and more each day to deleting that option all together and only allowing sanitized, obfuscate, or omit in the future.

[xuan-cao-swi]

Does sanitized mean specifically removing the sensitive data (e.g. token, password, ssn, health_id, etc.), but not other binding parameters such as address?

I believe most password stored in table should be hashed.

[arielvalentin]

Does sanitized mean specifically removing the sensitive data (e.g. token, password, ssn, health_id, etc.), but not other binding parameters such as address?

I think our current instrumentation uses the wrong vocabulary to describe what it does. Our current instrumentations use the word obfuscate, when I think we really mean is to sanitize, i.e. remove all user provided values.

I do not mean only targeting specific sensitive attributes when I use the word sanitize.

I now think of obfuscation as meaning that the entire query is hashed as opposed to just the parameters or values.

I brought up a request to change our vocabulary at a SIG meeting and the result #1194

Related to this topic, there was a recent OTEP submitted to around sensitive data redaction but I have not taken the time to digest it all just yet:

open-telemetry/oteps#255

[arielvalentin]

There are now experimental attributes db.operation.parameter.<key>

https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/sql.md#attributes