[Discussion] How to handle creating spans when PHP Generators are involved?

[dciprian-petrisor]

Hi,

Sorry for posting this as an issue, don't know where else to ask.
I am using open-telemetry/opentelemetry-auto-psr16 to automatically create spans for CacheInterface calls.
Among the hooked-into methods, there are some that return iterable via yield keyword (Generators) (e.g. getMultiple).

This results in one span for each yield call, resulting in very long traces.

Is there any way that these can be grouped or deduplicated?
Do maintainers consider this an issue?

Thank you!

[brettmc]

Hello and welcome.
That seems correct, according to the integration tests: https://github.com/open-telemetry/opentelemetry-php-contrib/blob/main/src/Instrumentation/Psr16/tests/Integration/Psr16InstrumentationTest.php#L120

I don't think that the iterator/generator is relevant here, the issue is that getMultiple seems to then call get for each param to getMultiple.

I think the correct OpenTelemetry solution to your issue would be to use sampling. Since getMultiple already records each of the cache keys, perhaps you could just sample out all of the get spans?

The collector's filterprocessor will probably do what you want - the telemetry will still be generated, but you can discard the noisy parts as part of the processing pipeline.

You might be interested in trying out our RuleBasedSampler. It's still fairly new, but I think you'll be able to use it to not generate the get's.

We've also recently added scope configuration, which allows turning off providers by name: https://github.com/open-telemetry/opentelemetry-php/blob/main/tests/Integration/SDK/Trace/TracerConfigTest.php#L25 It wouldn't work now with Psr16 since everything uses the same tracer name io.opentelemetry.contrib.php.psr16, but it could possibly be refactored to allow it to work with scope configuration.