Gateway Logging Levels and Thresholds

The gateway log includes fine-grained operational information. This is a partial list of the details you can see:
gateway10cr2
Container Gateway Users
The standard output for Container Gateways can now be integrated with third-party log stores and aggregation tools for greater scalability and higher availability in cloud deployments. See the Layer7 reference architecture for more information.
The
Layer7 API Gateway
log includes fine-grained operational information. This is a partial list of the details you can see:
  • Start-up of services within the Gateway
  • Database connection attempts and their results
  • Request message arrival, processing, and outcome information
  • Errors and exceptions
  • Optional detailed debugging information
The Gateway Log differs from the
Audit Log
. The Gateway Log includes fine-grained Gateway activity messages, whereas the Audit Log contains audit messages about more general runtime events and can only be viewed from within the Policy Manager. Audit Logs are described under "Understanding Logging Thresholds", later in this topic.
The Gateway's factory-configured logging should suffice for day-to-day use. You will need to modify it only under exceptional circumstances.
Logging Levels
The
Layer7 API Gateway
uses standard Java logging levels, in both its logging and auditing:
Logging Level
Description
FINEST
Reserved for code details that are generally not required for the day-to-day running of the Gateway. Normally not logged by the Gateway or audited.
FINER
Reserved for code details that are generally not required for the day-to-day running of the Gateway. Normally not logged by the Gateway or audited.
FINE
Reserved for code details that are generally not required for the day-to-day running of the Gateway. Normally not logged by the Gateway or audited.
CONFIG
Normal running events. First level of logging that is on by default.
INFO
Normal running events. First level of system auditing that is on by default.
WARNING
Events that do not always cause errors, but that could help you find other errors. For example, a policy assertion that fails generate a WARNING log. In this case, the Gateway did not fail, but an expected result -- the success of the policy assertion -- caused the warning. First level of message-level auditing that is on by default.
SEVERE
Level for serious or fatal errors in the Gateway, that either lead to inability to startup or inability to continue operating correctly. The Gateway failed on an essential operation.
ALL
All logs or audit events are logged.
OFF
No logs or audit events are logged
When the logging subsystem on the Gateway receives messages from various sources, these messages refer to a "facility", which can represent entities such as "authpriv", "kern", "user", "daemon", etc. Based on the facility, the logging subsystem determines where the message should be stored. For example, messages from the "authpriv" facility normally goes to
a /var/log/secure.*
log, while the
/var/log/messages.*
files store the majority of the messages.
By default, the Gateway is configured to provide logging at default set levels that are suitable for daily operation.
Understanding Logging Thresholds
The Gateway generates log events with a range of severities, as described in Java logging levels table.
The
log.levels
cluster property defines the threshold for log events that are processed by the configured log sinks (the minimum severity that is important enough to be processed).
Note that the
log.levels
property controls which log events must be propagated to the configured log sinks. Each log sink has a "threshold": only events that meet or exceed the threshold is processed by the log sink; all others are ignored.
If the log event severity is higher than the log level threshold, then the log event is propagated to the log sinks.
In order for a log event to be processed by a log sink, the severity of the event must meet or exceed the threshold defined by both the
log.levels
cluster property and by the log sink.
To alter the logging level threshold, modify the value of the
log.levels
cluster property and set the "<new_level>":
com.l7tech.level =
<new_level>,
to the desired value from Java Logging Levels table.
For more information on log sinks, refer to the following topics: