Gateway Auditing Threshold and Format
The gateway saves audit events in the database and you can view these in the window.
gateway92
The
CA 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.
- TheThis file controls the behavior of the particular Gateway or Gateway node (if part of a cluster).system.propertiesfile:The following properties control the audit thresholds:com.l7tech.server.audit.messageThresholdcom.l7tech.server.audit.adminThresholdcom.l7tech.server.audit.detailThresholdcom.l7tech.server.audit.hintingcom.l7tech.server.audit.assertionStatuscom.l7tech.server.audit.detailThreshold Respectedcom.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 thesystem.propertiesfile.
- For information on configuring cluster properties, see Manage Cluster-Wide Properties.
- For information on the audit settings that you can configure, see Audit Cluster Properties.
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
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).