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
I recently ran into a problem. My collector, which accepts span from the exporter, was unavailable for a while and therefore the application was also unavailable and a large number of requests fell with an error.
It seems to me that it is a good practice not to trigger errors in case of unavailability of the collector host, but to jam them. Usually, all systems for collecting metrics and errors behave like this.
Tell me please
Maybe I did not carefully study the documentation and did not find an opportunity to drown out such problems at the configuration level?
If there is no way to jam errors, do you plan to implement this, because if the application crashes if the metric collector is unavailable, this is a dangerous situation and forces you to abandon opentelemetry or redefine the exporter code to drown out exceptions that arise in the case of sending spans.
I think that the exporter should log and continue. The trace you've provided looks like the error being logged, and you can control where it gets logged to if that helps, or turn off logging entirely (see OTEL_PHP_LOG_DESTINATION)
If you're using a shared-nothing webserver setup, then I suspect that your problem was that because each request was timing out, the workers were not being freed up to service the next request, and you ran out of available workers/slots/whatever? That's unfortunately a symptom of the shared-nothing approach of those setups.
Recently, the spec has the addition of a file-based exporter. We haven't implemented it yet, but I wonder if you could combine it with the collector's filelogreceiver to give you that protection?
Hello, I am using open telemetry of this version
open-telemetry/exporter-otlp: "1.0.4"
open-telemetry/sdk: "1.0.8"
I recently ran into a problem. My collector, which accepts span from the exporter, was unavailable for a while and therefore the application was also unavailable and a large number of requests fell with an error.
It seems to me that it is a good practice not to trigger errors in case of unavailability of the collector host, but to jam them. Usually, all systems for collecting metrics and errors behave like this.
Tell me please
Will be answer, thank you
Error trace:
The text was updated successfully, but these errors were encountered: