Debugging policies can be difficult. We do have the policy debugger and we do have a debugging policy. Both tools help but the out-of-the-box debugging policy does not really produce a meaningful output. Here are a few tips to get you started.
All supported versions of the API Gateway
Without changing anything the Add audit Details assertion has this content:
TRACE: service.name=${trace.service.name} policy.name=${trace.policy.name} policy.guid=${trace.policy.guid} assertion.number=${trace.assertion.numberstr} assertion.shortname=${trace.assertion.shortname} status=${trace.status}
As you can see it contains strings such as "service.name", ... "policy.guid", ... these strings are used as labels. That is all good but it makes the audit result difficult to read. It also has the "trace.status" at the end although that may be the most important information you want to look at. Here is an example of the output:
What you are interested in are error codes (trace.status) and policy line numbers (trace.assertion.numberstr). But they are hidden in the log audit message at the end.
You can turn this message into something very helpful by replacing the content of the audit detail assertion using this message:
TRACE: [${trace.status}][${trace.assertion.numberstr}][${trace.assertion.shortname}][${trace.policy.name}]
I removed all labels and I moved the important content to the front. I have put variables into [...] brackets. The brackets will contain the following information:
The new output looks like this:
CA recommends not to turn on audits in production environments. If you need to keep Audits in production, we recommend not doing so internally on the Gateway servers, but relay the Audits to either an external DB, file system, or remote Syslog Server. If you need to Turn on audits in production please do so sparingly and revert the changes once they are no longer required. Keeping Audit logs on may fill up your database and bring down your environment. CA also recommends the use of a manage audit records script.