Pdo metrics #391
Pdo metrics #391
Conversation
GrzegorzDrozd
commented
Jun 16, 2025
GrzegorzDrozd
commented
- add duration tracking
- add returned rows tracking
- add pending operations metric
- add active connections metric
- minor code fixes
- add duration tracking - add returned rows tracking - add pending operations metric - add active connections metric - minor code fixes
- remove not needed debug code
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #391 +/- ##
============================================
- Coverage 82.82% 82.37% -0.46%
+ Complexity 1948 1898 -50
============================================
Files 142 140 -2
Lines 8142 7831 -311
============================================
- Hits 6744 6451 -293
+ Misses 1398 1380 -18 Flags with carried forward coverage won't be shown. Click here to find out more. see 2 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
@GrzegorzDrozd I've finally had some time to look at metrics generation. I started down the path of tracking everything in pre and post hooks, in #396 - when I got something working I started to realise that I was duplicating a lot of effort from tracing (and some attributes were really hard to get for a metric since you can start a span and add to it while it's in progress, whereas a metric is a single call). Since in my case (an HTTP server span), everything I need seems to be already stored in a span, I tried a different approach (I guess loosely based on span metrics connector and implemented a Span Processor to emit metrics: https://github.com/open-telemetry/opentelemetry-php/pull/1651/files#diff-9ed562697c2c477790ec9394f926eeb261f2433f39fb3eeca3e7999ee7c390dbR54 Looking at your implementation here, I see a similar pattern:
The metrics are closely related to the spans generated nearby. Given that duration and most of the attributes you're interested in are already in a span, do you think you could achieve your goals with a span processor? |
But that would force someone to use spans with metrics? What if they want only to use metrics? What about sampling? So with this argument I think I should move my code outside of hooks with spans and create separate code, so that we would allow using metrics without spans ... |
Yes it would...but we're creating spans anyway (even if they're no-op). Anyway, I'm not saying we have to do it that way, I just want to make sure we need the extra tracking/timing classes before accepting the ongoing maintenance. |
| $parent = Context::getCurrent(); | ||
|
|
||
| $instrumentation->meter() | ||
| ->createUpDownCounter('db.client.connection.count', '1') |
There was a problem hiding this comment.
Should we be creating a new instrument each time, or one that is reused?
