Customize 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
gateway91
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 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 variables that can be used in each cluster property.
Available for : | |||||||
|---|---|---|---|---|---|---|---|
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).