Is there a possibility that some request fails but does not catch by the trace session?
No. That is unlikely. The debugsession mechanism in Apigee is fairly mature and it won't "drop" messages or "miss" messages. It is possible for you to set a filter on a debugsession (aka Trace session) which tells Apigee to filter out only those messages that match the filter expression. But if you were using that, you would know.
Seems the fix also is to speedup the process on that proxy. Any suggestion on how to do that?
I don't know what you mean by this. The fix for what? And what do you mean, why would "speeding up the process" avoid a problem? I didn't quite understand your opening description of the trouble you're having.
We have a scenario wherein the client app that is calling an Apigee proxy that gives authorization didn't receive an auth token. We monitor this proxy, and it always has a full of request to stop the trace session. We continue to observe this, but we can't see a request that fails or has timeout.
One limitation of the debugsession is that it collects only the first 10 or 15 transactions, or so. There is a limit to the number of transactions the debugsession will capture, and for a production system experiencing production load, the limit is relatively low. If the proxy is under production load, 10's of transactions per second or more, then it will be relatively difficult to "catch" one transaction within there that is failing. For this reason the DebugSession (Trace) is not a good general purpose production diagnostics tool. It's helpful when you're building, but it's not as helpful when troubleshooting or diagnosing an ongoing production incident. For that, the best approach is LOGGING.
But, there is a way to set a filter on the debugsession when you create it. This exists in Apigee Edge SaaS and OPDK, and the flexibility of the filter capability has been greatly improved for hybrid and X. This can reduce the number of transactions the session will catch. If you are using hybrid or X, and if the problem is always experienced by one particular client which can be identified by one particular client ID, then... you can set the filter on the trace session to look for that particular client id. And that may raise the likelihood that you catch the problem in the trace session.
But, it's not foolproof. If the "client app" is deployed to 100k mobile devices, then there will still be many many transactions, and filtering on the clientid won't help you. But you may be able to filter on something else.
Check out the filtering on DebugSession and see if that helps.
LinkedIn
Twitter
