Do not mark span as error for 404 (preferably 4xx) HTTP status code

[sta-szek]

trafficstars

Is your feature request related to a problem? Please describe.

Kind of yes - we see spans as broken when server responds with 404 - which, according to RESTful guidelines is standard response when server has no data. Having no data is ok for the business.

Example problem:

As we can see, the server responded with 404, which is valid case in our implementation, and span is marked as error.

That makes it hard to filter out real broken requests.

Describe the solution you'd like

I would like to be able to configure for which status codes (regexp maybe?) the span should not be marked as error. Example: errorStatusCodes: ^5.+ or okStatusCodes: ^[2|3|4].+

Describe alternatives you've considered

No alternative, just bad search.

Additional context

I use autoinstrumentation: https://www.npmjs.com/package/@opentelemetry/auto-instrumentations-node

Would be really cool if the feature can be configured from there, preferably enabled by default.

[dyladan]

The current behavior is what is specified https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#status

Status

Span Status MUST be left unset if HTTP status code was in the 1xx, 2xx or 3xx ranges, unless there was another error (e.g., network error receiving the response body; or 3xx codes with max redirects exceeded), in which case status MUST be set to Error.

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.

Don't set the span status description if the reason can be inferred from http.status_code.

[sta-szek]

mhm... i see. It makes sense from the http point of view, but completely does not make sense if you apply RESTful rules on HTTP... 🤔

Just wondering, can we make it configurable, so we can mark the spans as "ok" or your recommendation is to apply filtering in kibana, grafana and jaeger, smth like: AND NOT (http.status_code="4.." AND span.kind="client") ?

The advantage would be that we can steer what error is for us. Of course, jaeger UI will not show us errors, if we filter by error=true

[dyladan]

I think there may already be request/response hooks which are used for adding attributes but could also be used to set the status. I don't know exactly the order they're called in and if setting the status would be overridden.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been stale for 14 days with no activity.