Percona offered an invaluable gift to the community when they provided an open source server-side thread pooling solution in lieu of Oracle’s MySQL Enterprise proprietary solution.
The next essential feature my organization (and I’m sure thousands of others) will need is Open Telemetry instrumentation. Oracle is offering a proprietary plugin for Open Telemetry in MySQL Enterprise. It looks great in 8.4 and like just what we need for full stack tracing and metrics. And in fact, my company is very close to requiring OTel integration with every slice of our stack. This will prevent us from continuing to use Percona’s Distribution for MySQL.
Does Percona have any plans to offer something analogous to the OTel plugin, akin to the server-side thread pooling feature?
Hello @sdavidson,
I can’t give you an official response on us adding Open Telemetry (above my pay grade 
) . What I did find with some googling is that there is already an open source otel collector for MySQL.
You should be able to run this on your Percona MySQL server, collecting the data and sending it to your OTel server/receivers. I can’t imagine why Oracle would need to release this as a plugin when all the metrics are already present through performance_schema.
I take it that you’ve already looked at, or are currently using Percona Monitoring and Management to collect metrics and such from MySQL? Since PMM uses VictoriaMetrics, there’s also a collector for that too into OTel.
1 Like
Thank you for your response. Of course you are right about metrics - no reason those can’t be collected via performance_schema and/or the otel collector you mentioned. But this is only true for metrics, not traces. To get trace span linking between client applications and the queries they issue to the DB, spans need to be “accepted” and “returned” (especially with connection pooling), or otherwise propagated. Further, per query traces that include explain plan elements, query execution costs, etc.; need to be able to associate the span id with EVENT_ID and NESTING_EVENT_ID. And if a query calls a stored procedure that calls several stored functions, good luck writing a general purpose perf_schema query to keep all that together. You want to do this while applying a trace sample rate (so as not to completely bog down the server with telemetry collection), or implementing some intelligent filtering like “only sample 5% of all queries, and all queries that took longer than 300ms.” Throw in some eBPF system call insights on a per-query trace, and I can easily see why a plugin would be needed.
You can get optimizer traces on queries, but that is done on an as-needed basis, not done continuously. You would need some sort of mechanism to flag a query pattern, and if matched, perform trace.
Further, per query traces that include explain plan elements, query execution costs, etc.;
You can get most of that already from EXPLAIN FORMAT=JSON
But yea, it would be a lot of work to add traces to MySQL.