Clarify semantic conventions around span start and end time#592
Conversation
yurishkuro
left a comment
There was a problem hiding this comment.
Why would we want to call this out just for HTTP spans? It is a general principle - if span represents an operation (be it an RPC or an internal function), its timestamps should be as close to operation start and end as possible.
I think that's fair. for http in particular web servers (and sometimes clients) incorporate some common middleware that adds to the cost of the request. I felt like the most ambiguity was there. I could take a stab at clarifying this is a more general place. |
Feedback states that the clarification around the meaning of the span start and end times could be more generic. Starting a proposal around by adding an example to the API.
|
One thing to consider is to make the Http example a more general RPC one. No strong feeling though. Overall good as an example ;) |
Rewording recommendation to use a more generic RPC Adding a small blurb clarifying sub operations can be instrumented.
1797a7d to
8099078
Compare
done! rewritten to a more generic RPC. |
|
Please resolve comments so we can get this merged :) |
Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Christian Neumüller <[email protected]>
|
@bogdandrutu addressed! |
|
@bogdandrutu these are addressed now, thanks! |
…emetry#592) * Adding http semantic conventions for span start and end times. * Corrected send to end, further clarified timings. * Moving span operation clarification to api Feedback states that the clarification around the meaning of the span start and end times could be more generic. Starting a proposal around by adding an example to the API. * Addressing feedback Rewording recommendation to use a more generic RPC Adding a small blurb clarifying sub operations can be instrumented. * Apply suggestions from code review Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Christian Neumüller <[email protected]> * Expanding on child spans Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Christian Neumüller <[email protected]>
…emetry#592) * Adding http semantic conventions for span start and end times. * Corrected send to end, further clarified timings. * Moving span operation clarification to api Feedback states that the clarification around the meaning of the span start and end times could be more generic. Starting a proposal around by adding an example to the API. * Addressing feedback Rewording recommendation to use a more generic RPC Adding a small blurb clarifying sub operations can be instrumented. * Apply suggestions from code review Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Christian Neumüller <[email protected]> * Expanding on child spans Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Christian Neumüller <[email protected]>
Fixes #591.
Adding semantic conventions for http start and end times. This has previously caused some ambiguity in the start / end times that instrumentations should target.