Gateway Auditing Threshold and Format

The gateway saves audit events in the database and you can view these in the window.
gateway92
The
Layer7 API Gateway
saves audit events in the database and you can view these in the View Gateway Audit Events window.
The Gateway logs audit events at the following default threshold levels:
Audit Events Category
Default Setting
Configurable?
System
ALL
No
Administrative
INFO
Yes
Message
WARNING
Yes
Associated
INFO
Yes
You can override the defaults for the event thresholds from the following locations.
Only system administrators or advanced technical users should attempt to change the auditing threshold and format. The default settings should suffice for normal use of the Gateway.
  • The
    system.properties
    file:
    This file controls the behavior of the particular Gateway or Gateway node (if part of a cluster).
    The following properties control the audit thresholds:
    com.l7tech.server.audit.messageThreshold
    com.l7tech.server.audit.adminThreshold
    com.l7tech.server.audit.detailThreshold
    com.l7tech.server.audit.hinting
    com.l7tech.server.audit.assertionStatus
    com.l7tech.server.audit.detailThreshold Respected
    com.l7tech.server.audit.purgeMinimumAge
  • Cluster Properties:
    Cluster property settings apply to all Gateway nodes in a cluster. Audit settings that are configured here override the same settings in the
    system.properties
    file.
Customizing the Audit Format for Logging
You can customize the format of audit messages that are recorded to a file or Syslog. There are three types of audit messages generated by the 
Layer7 API Gateway
  • Administrative actions
  • System events
  • Message processing events
These message types are described in greater detail in About Message Auditing.
For the purposes of customizing the audit format, the three message types are grouped into the following two categories:
  • Service-related
    : These are the message processing events
  • Other
    : These are the administrative actions and system events
The following terms are used to describe the parts of the audit information that can be customized:
  • header
    : This is the first log message related to processing of a message.
  • details
    : This is the detail log message for each audit detail.
  • footer
    : This is the final log message and relates to the audit record.
For service-related events, you can customize the header, footer, and details using these cluster properties:
Cluster Property
Description
Default
1
audit.log.service.headerFormat
Format for the first log message of a service audit
Processing request for service: {3}
2
audit.log.service.footerFormat
Format for the final (summary) log message of a service audit
{1}
3
audit.log.service.detailFormat
Format for details related to a service audit
{0}: {1}
4
audit.log.other.format
Format used for other (non-service) audit logs
{1}
5
audit.log.other.detailFormat
Format used for other (non-service) audit details
{0}: {1}
The following table describes in greater detail the placeholder variables that can be used in each cluster property.
Available for cluster properties
:
Variable
Description
Example
1
2
3
4
5
{0}
Audit message ID
1234
No
No
Yes
No
Yes
{1}
Audit message
Authentication required
No
Yes
Yes
Yes
Yes
{2}
Service entity ID
a1g38fj352da
Yes
Yes
Yes
No
No
{3}
Service description
Warehouse or
Warehouse [/warehouse]
Yes
Yes
Yes
No
No
For even greater flexibility, you can add a context variable before the {x} placeholder variables for service-related events. This will insert the contents of the specified context variable when the audit is logged. For example:
audit.log.service.headerFormat = ${requestId}: processing message.
audit.log.service.footerFormat = ${requestId}: {1}
audit.log.service.detailFormat = ${requestId}: {0}: {1}
When using context variables, the maximum length permitted per variable is 1000 characters. The overall message size is limited to 10000 characters, subject to any limitations of the sink (for example, syslog size limits).