Viewing and managing log messages is an important part of managing traffic on a network and maintaining a BIG-IP system. Log messages inform you on a regular basis of the events that are happening on the system.
You can log events either locally on the BIG-IP system or remotely, using The BIG-IP system’s high-speed logging mechanism. The recommended way to store logs is on a pool of remote logging servers.
For local logging, the high-speed logging mechanism stores the logs in either the Syslog or the MySQL database on the BIG-IP system, depending on a destination that you define. For remote logging, the high-speed logging mechanism sends log messages to a pool of logging servers that you define.
Examples of the types of messages that the high-speed logging mechanism can log are:
If you previously configured the BIG-IP system to log messages locally using the Syslog utility or remotely using the Syslog-ng utility, you can continue doing so with your current logging configuration, without configuring high-speed logging.
Alternatively, however, you can configure local Syslog logging using the high-speed logging mechanism, which is the recommended Syslog configuration. By configuring Syslog using high-speed logging, you can easily switch logging utilities in the future as needs change, without having to perform significant re-configuration.
The way that you set up remote, high-speed logging is by first defining a pool of logging servers, and then creating an unformatted, remote high-speed log destination that references the pool. If you are using ArcSight, Splunk, or Remote Syslog logging servers that require a formatted destination, you can also create a formatted log destination for one of those server types. Once those objects are set up, you create a publisher and a custom logging profile pertaining to the type of message you want to log. You then assign the logging profile to a relevant virtual server, and the profile, in turn, references the publisher.
This image shows the BIG-IP objects that you configure for remote high-speed logging. This figure shows the way that these objects reference one another from a configuration perspective.
For an example of configuring remote, high-speed logging, suppose you want to send all Protocol Security messages to a group of remote ArcSight servers. In this case, you would create these objects:
Although local logging is not recommended, you can store log messages locally on the BIG-IP system instead of remotely. In this case, you can still use the high-speed logging mechanism to store and view log messages locally on the BIG-IP system.
When you use the high-speed logging mechanism to configure local logging, the system stores the log messages in either the local Syslog data base or the local MySQL data base. The storage database that the BIG-IP system chooses depends on the specific log destination you assign to the publisher:
For each type of system-level process, such as bigdb configuration events or events related to HTTP compression, you can set a minimum log level. The minimum log level indicates the minimum severity level at which the BIG-IP system logs that type of event. There are many different types of local traffic or global traffic events for which you can set a minimum log level.
The log levels that you can set on certain types of events, ordered from highest severity to lowest severity, are:
For example, if you set the minimum log level for bigdb events to Error, then the system only logs messages that have a severity of Error or higher for those events.
If you are using the Syslog utility for local logging, whether or not you are using the high-speed logging mechanism you can view and manage the log messages, using the BIG-IP Configuration utility.
The local Syslog logs that the BIG-IP system can generate include several types of information. For example, some logs show a timestamp, host name, and service for each event. Moreover, logs sometimes include a status code, while the audit log shows a user name and a transaction ID corresponding to each configuration change. All logs contain a one-line description of each event.
For local log messages that the BIG-IP system stores in the local Syslog data base, the BIG-IP system automatically stores and displays log messages in these categories:
Each type of event is stored locally in a separate log file, and the information stored in each log file varies depending on the event type. All log files for these event types are in the directory /var/log.
Many events that occur on the BIG-IP system are Linux-related events, and do not specifically apply to the BIG-IP system. Using the Configuration utility, you can display these local system messages.
Some of the events that the BIG-IP system logs are related to packet filtering. The system logs the messages for these events in the file /var/log/pktfilter.
Many of the events that the BIG-IP system logs are related to local area traffic passing through the BIG-IP system. The BIG-IP system logs the messages for these events in the file /var/log/audit.
Audit logging is an optional feature that logs messages whenever a BIG-IP system object, such as a virtual server or a load balancing pool, is configured (that is, created, modified, or deleted). The BIG-IP system logs the messages for these auditing events in the file /var/log/audit.
There are three ways that objects can be configured:
Whenever an object is configured in one of these ways, the BIG-IP system logs a message to the audit log.
The BIG-IP system log messages contain codes that provide information about the system. You can run the Linux zcat command at the system prompt to expand the codes in log messages to provide more information. In this example, the bold text is the expansion of the log code 012c0012.
An optional type of logging that you can enable is audit logging. Audit logging logs messages that pertain to configuration changes that users or services make to the BIG-IP system configuration. This type of audit logging is known as MCP audit logging. Optionally, you can set up audit logging for any tmsh commands that users type on the command line.
For both MCP and tmsh audit logging, you can choose a log level. In this case, the log levels do not affect the severity of the log messages; instead, they affect the initiator of the audit event.
The log levels for MCP logging are:
The log levels for tmsh logging are:
If you want to configure remote logging using Syslog-ng, you do not use the high-speed logging mechanism. Configuration of remote logging using Syslog-ng has some key differences compared to a remote, high-speed logging configuration: