Otel event reporting in Laravel Cache listener: Performance issue with long Queue::work, consider alternative (Span?)

[flc1125]

A discussion. Regarding the Cache event listener of Laravel, it is currently reported based on Otel’s Event. But when a single Queue::work execution takes a very long time, the number of Events of a single Span will be very large, which will affect performance and the size of the reported data.

The minimum reporting unit of OTEL is a single Span, and the Event will be reported together as part of the data of the Span. If a single Span is very large, it is a burden in terms of network occupation, data size, etc.

Even before the reporting, the data stays in the memory, which is also a very big risk for the application.

Do we need to consider changing a way for reporting, for example: Span, etc.

A sample data:

• source: https://cloud-native.slack.com/archives/C01NFPCV44V/p1729165971570709
• code: https://github.com/open-telemetry/opentelemetry-php-contrib/blob/78a04cebaeba48d60a00dc1c48653695b926299d/src/Instrumentation/Laravel/src/Watchers/CacheWatcher.php#L30-L36

[ChrisLightfootWild]

Hey @flc1125 . Nice find - I'm going to test this locally and see if I can gain a better understanding of how we might overcome this.