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
Are there plans to migrate otellogrus or extending the capability of this repository to emit both - the log signal and the span event for all logging hooks? Of course this may lead to duplicate entries for setups where the pipeline or backend knows how to handle both simultaneously. Maybe the uptrace team has an opinion on this.
I'm sure the migration to just wrap the official package for otel-go is the right move in the long run, but imo it should be aligned across vendor hooks here and migration headaches should be considered before silently switching implementations affecting app and network/tool configuration.
For example: We've contributed to Grafana Alloy to support span events as logs via transformers, therefore our current setup relies on this fact. A sudden change in where and how logs are transmitted needs to be handled explicitly.
Hi,
I'm aware the otelzap package migrated to opentelemetry logs signals. Therefore my questions are:
I'm sure the migration to just wrap the official package for otel-go is the right move in the long run, but imo it should be aligned across vendor hooks here and migration headaches should be considered before silently switching implementations affecting app and network/tool configuration.
For example: We've contributed to Grafana Alloy to support span events as logs via transformers, therefore our current setup relies on this fact. A sudden change in where and how logs are transmitted needs to be handled explicitly.
Thanks!