Log numbers don't add up

[niwasystems]

As you can see in this screenshot the Error Code Analysis page is showing there were 1016 total errors during this time, and 636 were target errors. But on the Target errors chart it says the total error were 293. What happened to the 343 errors that were target errors but aren't on the target errors chart?

[snadella]

So looks like, not all target errors have a response code associated to them... i.e. if the target becomes un-reachable or ssl negotiation fails

[dchiesa1]

Right, so ... of the 636 "target errors" shown in the first chart, some portion of them could be due to TLS negotiation failures, and some could be successful connection, resulting in an unsuccessful HTTP response (4xx, 5xx). The third chart shows only the unsuccessful HTTP response.

Is it possible TLS is not configured properly?

If the Apigee side is misconfigured then we would expect see consistent TLS negotiation failures. I suppose if the backend (upstream) has multiple TLS termination points, and one of those is misconfigured, then... you would expect to see inconsistent behavior: some failures and some successful connections.

Has the TLS configuration been changing during that period? Is it possible that the config during 8 march was changed either on the backend or on the Apigee side?

[niwasystems]

We were having a bunch of problems at that time. Timeouts being the mostly likely, no reconfiguration of TLS as far as I'm aware. I'm prepared to accept that a no-response from the server is the cause of the lack of numbers, it would be nice if Apigee could show the count for 'unset' like they on other charts.

[#5]

Targets sometimes connect and start responding, before the full response is read it closes the connection then the connection is successful but the response code is error. This is the difference indicate to.