opentracing / specification

A place to document (and discuss) the OpenTracing specification. 🛑 This project is DEPRECATED! https://github.com/opentracing/specification/issues/163
http://opentracing.io/spec
Apache License 2.0
1.17k stars 182 forks source link

Introduce new tag to record client timeouts #121

Open yurishkuro opened 6 years ago

yurishkuro commented 6 years ago

Background

When analyzing traces for latency variance or the impact of SLOs of downstream on upstream services, it is useful to know if a client span was finished in error because of the timeout rather than a bad response from the server.

Proposal

Introduce a new tag timeout: bool, similar to error: bool, that the client span can be marked with.

Questions to address

We do not have clear recommendation on modeling timeouts and retries in the OT docs at the moment. Should there be some other tag that indicates that span B was a retry of span A because span A timed out?

objectiser commented 6 years ago

Definitely good idea to identify timeouts. Just wondering whether better to have a more general tag to allow for classifying other error types? e.g. error.type or error.kind (reusing the log field).

Are you suggesting a reference to represent the retry relationship? Would depend whether generally the span associated with the request being retried is available - although that is more of an implementation detail.

wu-sheng commented 6 years ago

+1 for timeout: bool tag.

pglombardo commented 6 years ago

If one error specific tag is added, eventually there will be requests for all error types such as DNS Lookup errors, NoResponse, SocketClosed etc... Supporting error specific tags may need a larger view/effort than just adding one specific one FWIW.