Consider using idiomatic zipkin tags about tracing-laravel HOT 3 OPEN

Hello @jcchavezs, the latest v0.7.0 release of the package incorporates some of the improvements that you kindly suggested including better default for HTTP span names and configuration options for logged headers.

That being said, I'll be withholding a transition to idiomatic Zipkin tags for now. It seems like OpenTracing semantic guide doesn't have a particularly varied selection of idiomatic tags and I'd rather not mix and match between these and our own custom ones unless there is good reason for it.

One such example is an error tag that we avail off in the latest release and helps with visually identifying spans for operations that couldn't be completed successfully. I am all for adopting names like these that have real practical benefits when working with query UI. Otherwise, I'd rather preserve consistency across all implementations that happen to already consume this package which affects us internally at Vinelab also.

I'll keep this discussion open for reference and in case we discover other uses for idiomatic tags that are worth exploring.

from tracing-laravel.

Thank you for the feedback, there is a lot of good suggestions here. I made plans to include these in future versions of the package.

from tracing-laravel.

Another use case: Idiomatic tags like span.kind seem to be required in order to take advantage of things like Grafana Tempo's Service Graphs (https://grafana.com/docs/tempo/latest/metrics-generator/service_graphs).

from tracing-laravel.