You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@ChrisLightfootWild
I had a shower thought the other day. Could we not allow custom commands to specify if they are long running, and have a whitelist of built-in commands that should not be spanned? Such as queue:work and octane:start etc?
Maybe it could even be an attribute?
Maybe also an env to merge into the whitelisted commands, for vendor commands etc.
#[LongRunningCommand]
class KafkaConsumer extends Command
It should be because of the OTEL_SPAN_EVENT_COUNT_LIMIT configuration, so the event with the largest single span only supports 128. So, my dashboard sees 128.
A discussion. Regarding the
Cache
event listener of Laravel, it is currently reported based on Otel’s Event. But when a singleQueue::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.Do we need to consider changing a way for reporting, for example:
Span
, etc.A sample data:
The text was updated successfully, but these errors were encountered: