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
It would be convenient to provide a way to specify routes and/or status codes are not exceptional.
A common pattern within Pyramid is to raise the desired response for certain business flows (e.g. raise a 301 to force a redirect, raise a 204 after deleting an entity, etc) rather than properly return. Because the response was raised and handled as an HTTPException the span is decorated with exception attributes even though the request was not actually exceptional. This causes many vendors to interpret a false-positive when calculating things like error rate.
There is history of this functionality in other instrumentation:
Having investigated this further, it looks like Pyramid instrumentation is miscategorizing most 200s and 300s exceptions as errors. Created a pull to fix that.
I if understand correctly, we should ignore 4xx as well and only record 5xx exceptions as errors. According to the spec:
For HTTP status codes in the 4xx range span status MUST be left unset in case of SpanKind.SERVER and MUST be set to Error in case of SpanKind.CLIENT.
For HTTP status codes in the 5xx range, as well as any other code the client failed to interpret, span status MUST be set to Error.
I think we are talking only about server spans here right? In that case only 5xx should be set to the span status as an error unless I misunderstood something.
It would be convenient to provide a way to specify routes and/or status codes are not exceptional.
A common pattern within Pyramid is to raise the desired response for certain business flows (e.g. raise a 301 to force a redirect, raise a 204 after deleting an entity, etc) rather than properly return. Because the response was raised and handled as an
HTTPException
the span is decorated with exception attributes even though the request was not actually exceptional. This causes many vendors to interpret a false-positive when calculating things like error rate.There is history of this functionality in other instrumentation:
The text was updated successfully, but these errors were encountered: