Add utility classes and tests for Timer and Attribute tracking by id …

[GrzegorzDrozd]

…and object

Introduced TimerTrackerById, TimerTrackerByObject, AttributeTrackerById, and AttributeTrackerByObject classes for managing timers and attributes based on id or object references.

This will be used by auto instrumentation and metrics in contrib modules.

[brettmc]

• I'd like to understand how this would be used by an instrumentation package. The metrics implementation is pretty extensive, does it already have features that can be used? I'd prefer to see a metrics implementation PR in an existing package, using this code locally, before extracting it to a re-usable place
• would we have a need for metrics to be tracked across different instrumentation packages?
• instrumentation packages are actively discouraged (per spec) from depending on the SDK

[ChrisLightfootWild]

For any time related operations, there's also already clock functionality in the API - so it might make sense to utilise that over the raw calls to microtime.

[GrzegorzDrozd]

@brettmc Usage example is here: open-telemetry/opentelemetry-php-contrib#391

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[GrzegorzDrozd]

Hi @brettmc , somehow I missed this notification :/

• I'd like to understand how this would be used by an instrumentation package. The metrics implementation is pretty extensive, does it already have features that can be used? I'd prefer to see a metrics implementation PR in an existing package, using this code locally, before extracting it to a re-usable place

For example: TimerTrackerById would keep timers for everything that sending external requests: PDO, Redis, HttpClient, Curl, Guzzle etc. Everything that needs to get duration.

* would we have a need for metrics to be tracked across different instrumentation packages?

Instance of a tracker would be created in ::register of a given contrib package. It would not be shared.

* instrumentation packages are actively discouraged (per spec) from depending on the SDK

Well we can copy and paste those classes all over but that would also be a bad practice.

Maybe some form of cross contrib code share? We could do some namespace shenanigans and have shared code just copied to a contrib module?
From this:

  "autoload": {
    "psr-4": {
      "OpenTelemetry\\Contrib\\Instrumentation\\PDO\\": "src/"
    },
    "files": [
      "_register.php"
    ]
  },

to

  "autoload": {
    "psr-4": {
      "OpenTelemetry\\Contrib\\Instrumentation\\PDO\\": "src/",
      "OpenTelemetry\\Contrib\\Instrumentation\\Shared\\": "shared/"
    },
    "files": [
      "_register.php"
    ]
  },

Or even put everything into one file and use files + copy into every contrib?

[brettmc]

Well we can copy and paste those classes all over but that would also be a bad practice.

Agreed, that sounds awful! The most likely place is its own package in contrib, or in our API. If it goes into API, then under API\Instrumentation feels like the right place - we already have some code there to support auto-instrumentation 🤔