auto-instrumentation registration #1304
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1304 +/- ##
============================================
- Coverage 74.61% 74.20% -0.41%
- Complexity 2504 2562 +58
============================================
Files 355 372 +17
Lines 7180 7386 +206
============================================
+ Hits 5357 5481 +124
- Misses 1823 1905 +82
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 9 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
src/API/Instrumentation/AutoInstrumentation/Instrumentation.php
Outdated
Show resolved
Hide resolved
src/API/Instrumentation/AutoInstrumentation/ExtensionHookManager.php
Outdated
Show resolved
Hide resolved
src/API/Instrumentation/AutoInstrumentation/ExtensionHookManager.php
Outdated
Show resolved
Hide resolved
- deptrac was rightly complaining that API (indirectly) depended on SDK through config/sdk. For now, remove usage of Config\SDK\Configuration\Context - update deptrac config to allow some new dependencies
psalm doesn't complain now, so that should be good
- make "register global" a function of Sdk, but keep the sdk builder's interface intact - invent an API instrumentation context, similar to the one in config/sdk, to pass providers to instrumentations - add an initial test of autoloading from a config file
in passing, remove some dead code for handling invalid booleans - config already handles this correctly
src/API/Instrumentation/AutoInstrumentation/ExtensionHookManager.php
Outdated
Show resolved
Hide resolved
src/API/Instrumentation/AutoInstrumentation/ExtensionHookManager.php
Outdated
Show resolved
Hide resolved
allow SDK created from config file to coexist with components using globals initializer
not available in phpunit 10, so comment out and leave a todo
|
@open-telemetry/php-approvers @Nevay I think I'm happy with this and it's ready for review! NB that we should not merge until a new version of opentelemetry-config is tagged, which should be v0.3 |
| foreach ($value as $name => $v) { | ||
| $provider = $this->providers[$type][$name]; | ||
| $this->resources?->addClassResource($provider); | ||
| $validated[] = new ComponentPlugin($v, $this->providers[$type][$name]); | ||
| } |
There was a problem hiding this comment.
If we could work out a way to provide the default config rather than empty (ie, by processing the InstrumentationConfiguration without input), it might work a bit better?
We could add an additional flags that allows instantiating all component plugins by iterating over $this->providers[$type] instead of $value to provide default configurations for instrumentations.
| ; | ||
| }); | ||
| if (Configuration::has(Variables::OTEL_EXPERIMENTAL_CONFIG_FILE)) { | ||
| Globals::registerInitializer(fn ($configurator) => self::fileBasedInitializer($configurator)); |
There was a problem hiding this comment.
We'll need to disable the hook manager during initialization to avoid autoinstrumenting the SDK.
There was a problem hiding this comment.
Discussed at SIG, and we couldn't think of a scenario where SDK would be instrumented only during initialization?
There was a problem hiding this comment.
The SDK might use classes/methods that are autoinstrumented by a user (http clients etc.); SDK exports use the context that was active during the SDK initialization (related: #1304 (comment)) -> disabling the hooks during initialization disables them for all SDK exports.
(AFAIK Java avoids this issue by loading autoinstrumentation classes in a separate classloader)
There was a problem hiding this comment.
Understood (and I now remember this happening in #878 ). I think I've done this (by making hookmanager enable/disable static methods which seemed the cleanest solution) - WDYT?
There was a problem hiding this comment.
If we want to make enabling/disabling static: methods should be moved out of ExtensionHookManager.
Alternatively we could provide an accessor to the global hook manager and still allow enabling / disabling hook managers independently.
There was a problem hiding this comment.
ok, re-jiggered things a little by moving the static methods into HookManager. How does this approach look?
The main wart I see is that I renamed the existing interface, HookManager to HookManagerInterface which looks untidy in composer.json's extra.spi. But, HookManager::disable() seemed like the most obvious approach.
The most obvious place to do this is in a class named HookManager, which _was_ an interface for hook managers. Rename existing HookManager to HookManagerInterface, then re-purpose HookManager for globally enabling/disabling hook managers as well as determining the disabled status.
OTEL_EXPERIMENTAL_CONFIG_FILEdefines where the SDK config file resides (relative to CWD), and also acts as a trigger to autoload via SPI rather than our current env-based versiontodo: