[discuss]: How to distinguish whether the 5xx status code (eg 500) comes from upstream or apisix

[Firstsawyou]

Issue description

When our http request gets an error status code 5XX, for example: 500. How do we know if this status comes from upstream or apisix.

To know the source of the error status code, I think that in the response phase (header_filter), we can determine that the upstream response code is equal to 5XX. When it is equal to 5XX, we can set relevant headers in the response header to achieve our goal.

[tokers]

We may resort to the logging or tracing to determine this difference.

The way you described is more like a debugging way, maybe it can be expanded to support more demands.

[spacewander]

Why not use $upstream_status?

[Firstsawyou]

We may resort to the logging or tracing to determine this difference.

The way you described is more like a debugging way, maybe it can be expanded to support more demands.

I think if we can know the source of the abnormal request (upstream or apisix) directly through the http response header, then we don't need to track the request or check the logger. For example: an http request returns a 500 status code. If relevant information is recorded in the response header, we can directly know where the problem occurred, and there is no need to track or view the record to determine the problem.

[Firstsawyou]

Why not use $upstream_status?

The meaning expressed in the description is to use $upstream_status, which may be a bit abstract in the description. ^ . ^

[tokers]

We may resort to the logging or tracing to determine this difference.
The way you described is more like a debugging way, maybe it can be expanded to support more demands.

I think if we can know the source of the abnormal request (upstream or apisix) directly through the http response header, then we don't need to track the request or check the logger. For example: an http request returns a 500 status code. If relevant information is recorded in the response header, we can directly know where the problem occurred, and there is no need to track or view the record to determine the problem.

The example you took is a relatively simple situation, problem like timeout is more sophisticated, you cannot know the cause oftimeout (connect, SSL handshake, read or write) without extra information in HTTP headers, in such a case, you still have to use other tools. Or we have to record enough messages in HTTP headers, which is heavy. At least we cannot enable this feature for all requests, maybe a switch is needed.

[gxthrj]

I agree with this idea, it will speed up the speed of finding problems out, no need to check the log.
We can add x-apisix-upstream-* in the response header.
e.g.

When upstream returns 5xx, we get a response like this

< HTTP/1.1 5xx *********
< Date: xxx
< Content-Type: application/json; charset=UTF-8
< Connection: keep-alive
< Server: apisix/1.5.0
< X-Apisix-Upstream-address: 10.10.10.10:8080
< Via: apisix/1.5.0

When upstream times out, we can get a response like this

< HTTP/1.1 504 Gateway Time-out
< Date: xxx
< Content-Type: application/json; charset=UTF-8
< Connection: keep-alive
< Server: apisix/1.5.0
< X-Apisix-Upstream-Latency: 30002
< Via: apisix/1.5.0

[membphis]

agree +1 ^_^

[idbeta]

I agree with the idea of adding a new field in the response header.

[membphis]

welcome PR to fix this issue ^_^

[moonming]

any update?

[Firstsawyou]

I will submit a PR later to solve this problem.

[Firstsawyou]

assigned to me.