No Database information in exporter traces

[evoicefire]

Describe the bug I am not sure if this is a usage error, a bug or should be a feature request. So let me know if I need to put this in a different spot.

I have enabled the "database" listener. I expected this to mean that information about database queries (ie. what query and how long it took) would be included in the trace data exporter into Jaeger (or whatever trace solution used).

However, all I see are spans relating to WP Core (presumably the "WordPress core" listener). I expected (perhaps incorrectly) that my spans would have what database queries were triggered and how long they took (in an ideal world it would also include any external HTTP requests and how long they took (what line of PHP triggered the request and what parameters were passed).

I was expecting something similar to what is discussed here (https://woocart.com/blog/slow-wordpress)

To Reproduce Steps to reproduce the behavior:

1. Use this docker-compose file:

   ---
   version: '3'
   services:
   db:
   # We use a mariadb image which supports both amd64 & arm64 architecture
   image: mariadb:10.6.4-focal
   # If you really want to use MySQL, uncomment the following line
   #image: mysql:8.0.27
   command: '--default-authentication-plugin=mysql_native_password'
   volumes:
     - db_data:/var/lib/mysql
   restart: always
   environment:
     - MYSQL_ROOT_PASSWORD=somewordpress
     - MYSQL_DATABASE=wordpress
     - MYSQL_USER=wordpress
     - MYSQL_PASSWORD=wordpress
   expose:
     - 3306
     - 33060
   wordpress:
   image: wordpress:latest
   ports:
     - 80:80
   restart: always
   environment:
     - WORDPRESS_DB_HOST=db
     - WORDPRESS_DB_USER=wordpress
     - WORDPRESS_DB_PASSWORD=wordpress
     - WORDPRESS_DB_NAME=wordpress
   grafana:
   image: grafana/grafana:8.1.6
   volumes:
     - ./ds.yaml:/etc/grafana/provisioning/datasources/datasources.yaml
   environment:
     - GF_AUTH_ANONYMOUS_ENABLED=true
     - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
     - GF_AUTH_DISABLE_LOGIN_FORM=true
   ports:
     - "3000:3000"
   
   jaeger:
   image: jaegertracing/all-in-one:latest
   ports:
     - '6831:6831'
     - '16686:16686'
     - '14268:14268'
   volumes:
   db_data:

2. Setup Wordpress and install Decalog. Configure Decalog to ship traces to the jaeger instance. Add the jaeger datasource to Grafana.
3. Navigate through the Wordpress site and search through the Spans. Open any of the spans and there is no data surround SQL queries.

Expected behavior data about SQL queries

Screenshots

Environment (please complete the following information):

Database (MariaDB 10.6.4)
Metatraces listener (DecaLog 3.5.1)
PHP (PHP 7.4.30)
Prometheus-compliant listener (DecaLog 3.5.1)
PSR-3 compliant listeners (DecaLog 3.5.1)
WordPress core (WordPress 6.0.2)

Additional context Add any other context about the problem here.

[Pierre-Lannoy]

Hello @evoicefire ! First of all, thank you so much for this detailed report ❤️ Your question is valid: bug or feature request? Well, for a quick answer: it's not a bug because nothing is implemented to do that. There are many reasons for why it is not - for now. Performance, exhaustiveness, trigger threshold, dev vs. prod, etc. But the main reason is DecaLog is about PHP, not "really" database. Nevertheless, your suggestion (to implement such a db tracing "engine") is totally legit. And I think, like you, that something must be done about this: I don't know yet if it should be done right in DecaLog or in a "companion plugin" - a plugin on top of DecaLog. Let me think about it… For now, I tagged your report as "enhancement", and I'll let you know my thoughts as soon as I've managed to weigh the pros and cons. Thanks again for your report.

[Pierre-Lannoy]

Hello @evoicefire ! As you cans see in the last commit, I've made the choice to include right in DecaLog the ability to:

• collate SQL queries as spans in traces;
• trigger an event for each slow SQL query (with a 50ms threshold).

It will be in the next DecaLog version (3.6.0) which will be ready before GA of WordPress 6.1.

Thanks again for pushing me to think about this again.

[gmintoco]

@Pierre-Lannoy Wow! Thanks a lot for your attention I didn't expect this to be picked up so soon (or at all ;) ) much appreciated! I will make sure to give it a try as soon as possible.

My other idea that could be very useful was hooking into the Wordpress HTTP library (guzzle I think) and tracing external HTTP requests (ie. an example from our use case is that when searching the Wordpress site a request is sent to elasticsearch to fetch results, timing that along with collecting details like which URL was requested and with which parameters would be handy.

I might try and see if I can have a look at how you implemented the database tracing and potentially emulate something similar for HTTP requests :)

[Pierre-Lannoy]

Thanks ;)

Regarding the HTTP activity in WordPress: no it's not relying on Guzzle. WordPress have its own library (yes, I know, please no comment 🤣) That's the bad news. The good one is: I've developed a plugin to make this library "observable" (in a standalone way, or in conjunction with DecaLog). You can give it a try: https://github.com/Pierre-Lannoy/wp-traffic

[Pierre-Lannoy]

In a general way, I made some plugins that are related to observability and performance. They are all free https://perfops.one

[Pierre-Lannoy]

Hello! Version 3.6.0 is released. Could you confirm it fixes your issue? Thanks 😉

[gmintoco]

Hey, I just checked it out and it looks great! This will be a really great feature for debugging performance issues for sure. I am looking forward to installing this on our sites to start collecting some performance data :)

I also tried out 'wp-traffic' which also looked really good for looking at API calls. I was wondering if it was meant to integrate into the tracing component of decalog (ie. user makes request to page, Wordpress has an outgoing API call needed to service that request - request would be logged in the trace span and pushed to jaeger) or is it just independent to decalog?

[Pierre-Lannoy]

Hello @gmintoco ! Thanks for your feedback ❤️ Regarding wp-traffic, it doesn't trace api calls, but you're right, it may be a good suggestion to do 😉