Applies To:

Show Versions Show Versions

Manual Chapter: Event Logging
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

14 
Viewing and managing log messages is an important part of maintaining a BIG-IP® system. Log messages inform you on a regular basis of the events that are happening on the system. Some of these events pertain to general events happening within the operating system, while other events are specific to the BIG-IP system, such as the stopping and starting of BIG-IP system services.
The mechanism that the BIG-IP system uses to log events is the Linux utility syslog-ng. The syslog-ng utility is an enhanced version of the standard UNIX and Linux logging utility syslog.
System events
System event messages are based on Linux events, and are not specific to the BIG-IP system.
Packet filter events
Packet filter messages are those that result from the implementation of packet filters and packet-filter rules.
Local traffic events
Local-traffic event messages pertain specifically to the local traffic management system.
Audit events
Audit event messages are those that the BIG-IP system logs as a result of changes to the BIG-IP system configuration. Logging audit events is optional.
To configure and manage event logging, log in to the BIG-IP Configuration utility, and on the Main tab, expand System, and click Logs.
The logging mechanism on a BIG-IP system includes several features designed to keep you informed of system events in the most effective way possible:
One of the primary features of the logging feature is its ability to log different types of events, ranging from Linux system events, to packet filtering events, to local traffic events. Through the BIG-IP system auditing feature, you can even track and report changes that users make to the BIG-IP system configuration, such as adding a virtual server. For more information, see Understanding log content, and Understanding log types.
When setting up logging on the BIG-IP system, you can customize the logs by designating the minimum severity level, or log level, that you want the BIG-IP system to report when a type of event occurs. The minimum log level indicates the minimum severity level at which the BIG-IP system logs that type of event. For example, you can specify that, for any change a user makes to the bigdb database, the minimum severity level for which the BIG-IP system logs messages is Warning. This means that the BIG-IP system logs Warning and more severe messages such as Error and Critical messages, but not less severe ones such as Notice, Informational, or Debug messages. For more information, see Setting log levels.
You can also use the Configuration utility to search for a string within a log event, that is, filter the display of the log messages according to the string you provide. For more information, see Viewing and filtering log messages.
On systems with hard drives, the system allocates a defined amount of space for the log file. The default size of this log file is 7 gigabytes. Using the BIG-IP systems resize-logFS command, you can change the size of the log file. For information on managing the size of the log file, see Managing the size of the log file.
You can view historical logs using the Traffic Management shell (tmsh). For more information, see the Traffic Management Shell (tmsh) Reference Guide.
You can implement HTTP request logging, For more information, see the HTTP Request Logging profile from within BIG-IP® Local Traffic ManagerTM.
Finally, you can log BIG-IP system events to a remote logging server. You do this by identifying the IP address or host name of the remote logging server, and creating an encrypted network connection, or tunnel, for sending log information to that remote server.
Tip: You can also configure the system to send email or activate pager notification based on the priority of the logged event.
The logs that the BIG-IP system generates 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 1-line description of each event.
Table 14.1 lists the categories of information contained in the logs and the specific logs in which the information is displayed.
System
Packet Filter
Local Traffic
Audit
The host name of the system that logged the event message. Because this is typically the host name of the local machine, the appearance of a remote host name could be of interest.
System
Packet Filter
Local Traffic
System
Packet Filter
Local Traffic
The status code associated with the event. Note that only events logged by BIG-IP system components, and not Linux system services, have status codes.
Packet Filter
Local Traffic
System
Packet Filter
Local Traffic
Use the Configuration utility for an easy way to view the log files that the system generates. You can also control which messages the Configuration utility displays, by typing a search string.
Note: An alternate way to view and filter log messages is to use tmsh. For more information, see the Traffic Management Shell (tmsh) Reference Guide.
On the BIG-IP system, you can use the Configuration utility to view standard system, packet filter, local traffic, or audit messages.
1.
On the Main tab of the navigation pane, expand System, and click Logs.
The Logs screen opens.
2.
On the menu bar, click System, Packet Filter, Local Traffic, or Audit, depending on the type of log messages you want to view.
This displays a list of this type of log message.
3.
If you want to advance to another screen of messages, first locate the page list at the lower-right corner of the screen. You can either:
The BIG-IP system log messages contain codes that provide information about the system. You can run the Linux cat command at the system prompt to expand the codes in log messages to provide more information. In Figure 14.1, the bold text is the expansion of the log code 012c0012.
Jun 14 14:28:03 sccp bcm56xxd [ 226 ] : 012c0012 : (Product=BIGIP Subset=BCM565XXD) : 6: 4.1 rx [ OK 171009 Bad 0 ] tx [ OK 171014 Bad 0 ]
You can view log files for a specific range of dates. To do this, you use the show log command within the sys module of the Traffic Management shell (tmsh). For more information, see the Traffic Management Shell (tmsh) Reference Guide.
You can view the command audit log by date range, using the Traffic Management shell (tmsh). For more information, see the Traffic Management Shell (tmsh) Reference Guide.
1.
On the Main tab of the navigation pane, expand System, and click Logs.
The Logs screen opens.
2.
On the menu bar, click System, Packet Filter, Local Traffic, or Audit, depending on the type of log messages you want to view.
This displays log messages of the type you selected.
3.
In the Search box (directly above the Timestamp column), type a string, optionally using the asterisk as a wildcard character.
4.
Click Search.
This displays only those messages containing the string you specified.
As described in Introducing BIG-IP system logging, the BIG-IP system automatically logs four main event types: system, packet filter, local traffic, and configuration changes (audit). Each type of event is stored 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.
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/ltm.
Packet Velocity® ASIC (PVA) configuration events
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).
Using the Configuration utility, you can display audit log messages. Table 14.4 shows a sample audit log entry. This example shows that user janet enabled the audit logging feature.
DB_VARIABLE modified:
name="config.auditing"
Using the Configuration utility, you can set log levels on both local traffic and auditing events. For each type of local traffic event, 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. For more information, see Setting log access, following.
For auditing events, you can set a log level that indicates the type of event that the system logs, such as the user-initiated loading of BIG-IP system configurations, or system-initiated configuration changes. For more information, see Setting log levels for auditing events.
Note: An alternate way to set log levels is to use tmsh. For more information, see the Traffic Management Shell (tmsh) Reference Guide.
You can control a users access to the logs by setting the users user role to either Allow or Deny. On the Main tab, expand System, click Logs, and on the menu bar, click Options.
For local traffic events, you can set a minimum log level. Thus, for different kinds of local traffic events, such as bigdb configuration events or events related to HTTP compression, you can set different minimum log levels.
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 retain the default minimum log level (Informational), then the system logs all messages that have a severity of Informational or higher (that is, all messages except Debug messages).
There are many different types of local traffic events for which you can set a minimum log level. Table 14.5, shows the types of local traffic events and the minimum log levels that you can configure for them. Because not all log levels are available for every local-traffic event type, the table shows the specific log levels you can set on each event type. Following the table is the procedure for setting the minimum log level on a local traffic event type.
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. (For more information, see Auditing configuration changes.) 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 one of four log levels. 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 and tmsh audit logging are:
Disable
This turns audit logging off. This is the default value.
Enable
This causes the system to log messages for user-initiated configuration changes only.
Verbose
This causes the system to log messages for user-initiated configuration changes and any loading of configuration data.
Debug
This causes the system to log messages for all user-initiated and system-initiated configuration changes.
You can view the contents of the audit log, or you can search an audit log based on user name, time period, or specific content.
On the Main tab, expand System, click Logs, and on the menu bar, click Audit.
When you initially start the BIG-IP system, the system allocates a finite amount of disk space for storing the log file. The advantage to having a finite size for the log file is that the file cannot increase to the point where it adversely affects other facilities that are running on the system in the same Linux® partition.
The default amount of disk space that the BIG-IP system allocates for the log file is 7 gigabytes (Gb). In most cases, this is sufficient space for the log file. However, you can either allocate additional disk space, or decrease the amount of disk space allocated for the log file. The minimum amount of disk space that you can specify for the log file is 1 Gb. The maximum amount of disk space that you can specify is 10 Gb.
You adjust the amount of disk space that the system allocates for the log file by using a command line script named resize-logFS. When you use the resize-logFS script, the system prompts you for information, and validates two facts:
Warning: Before using the resize-logFS script, it is imperative that you stop the BIG-IP system, or put the system into a safe condition such as standby mode.
1.
Stop the BIG-IP system or put the system into a safe condition such as standby mode.
You can stop the BIG-IP system using the command bigstart stop.
Note: This command prompts you for the file size in gigabytes.
3.
At the prompt, type an integer. The minimum allowed value is 1, and the maximum allowed value is 10.
A prompt appears that allows you to confirm the specified file size.
4.
Type Y.
A message appears, notifying you of the need for the BIG-IP system to perform a reboot, followed by a prompt, which allows you to permit the reboot operation.
Note: Prior to rebooting, the BIG-IP system verifies that the integer you typed in step 3 is within the allowed range, and checks to ensure that enough disk space exists for the specified size.
5.
Type Y.
A confirmation prompt appears.
6.
Type Y.
The system displays messages indicating that the reboot operation is about to occur.
7.
Wait for the reboot operation to finish.
When the system becomes available again, the newly-specified disk space for the log file is in effect.
If, at any time during the resize-logFS operation, you decide to exit the script, no reboot occurs and the amount of allocated disk space remains as is.
You can configure the syslog-ng utility on the BIG-IP system to send BIG-IP system log information to a remote logging host, using an encrypted network connection. To do this, you create a port-forwarding SSH tunnel to the remote logging host, and configure the syslog-ng utility on the BIG-IP system to send log messages through the SSH tunnel.
Before you attempt to configure encrypted remote logging, you must meet the following conditions on the BIG-IP system and your remote logging host:
On the BIG-IP system
You must have a console with root access to the BIG-IP system.
On the remote logging host
You must have a console with root access to the remote logging host, the IP address, or the host name of the remote logging host.
For both systems
You must have both systems connected to the same subnetwork.
Warning: Attempt this configuration only if you understand the risks associated with making changes to daemon startup scripts.
Edit the syslog-ng utility startup script to create and destroy the SSH tunnels.
Edit the remote logging host to accept syslog-ng messages through the SSH tunnel.
This configuration requires that the BIG-IP system is able to establish an SSH connection to the remote logging host. On the BIG-IP system, use the ssh command to create the tunnel. Figure 14.2 is an example of the syntax required to create an SSH tunnel.
Table 14.6 contains detailed descriptions of the ssh syntax elements shown in Figure 14.2.
The port SSH listens on for connections in order to forward them to <remote log hostname>:<remote tunnel port>.
<remote log hostname>
The port to which you want the SSH daemon on the remote logging server to forward connections.
The user name that SSH attempts to authenticate, as on <remote log hostname>.
After you have reviewed the ssh command syntax, use the ssh command to create the encrypted tunnel on the BIG-IP system. You must create a unique key on the BIG-IP system. The unique key is used to identify and authorize the BIG-IP system to the remote logging host.
To create the file syslog_tunnel_ID and syslog_tunnel_ID.pub, use the following command sequence:
To make syslog_tunnel_ID readable only by the root account, use the following command sequence:
To make the public portion of the unique SSH ID named syslog_tunnel_ID.pub readable by all accounts, use the following command sequence:
Copy syslog_tunnel_ID and syslog_tunnel_ID.pub into /var/ssh with the following command:
Next, you must change the syslog-ng utility startup script, /etc/init.d/syslog-ng, so that the encrypted tunnel is opened when the syslog-ng script starts up, and is closed when the script is restarted or stopped.
Before you edit the syslog-ng utility startup script, save a backup copy to the root directory. Use the following command to save the backup to the root directory:
After you save a backup of the syslog-ng utility startup script, /etc/init.d/syslog-ng, edit it to automatically create SSH tunnels when the syslog-ng utility is started, or close the SSH tunnels when the syslog-ng utility is restarted or stopped.
The example configuration in this document demonstrates how to create a tunnel to a host using the following IP addresses and ports:
IP address of 10.0.0.100
User name logger on host 10.0.0.100
Start by adding syntax below the line that reads start). Figure 14.3 is an example of what the section of the syslog-ng start script looks like after you add the new syntax. In this example, the syntax you need to add is shown with bold text.
ssh -L 5140:10.0.0.100:5140 \
Next, add syntax below the line that reads stop). Figure 14.4 shows the syntax you need to add in bold text.
for sshTunnel in \
After you add the syntax to open and close SSH tunnels, you can modify the configuration of the syslog-ng utility to log messages to the remote machine. To do this, you need to create source and filter configuration blocks based on the local environment. Using the sample IP addresses and ports shown in the previous section, use the syslog command to set up the remote logging host.
After you have used the syslog command to set up the remote logging host to log messages, you must copy the unique SSH identity to the remote logging host. To do this, copy the syslog_tunnel_ID.pub identity to the remote syslog server, and append this key to the authorized_keys file found in the .ssh folder under the home directory of the user that you want to use to capture remote log messages.
Verify that the logging facility is configured and ready to receive syslog-ng messages on the <remote tunnel port>. If the remote logging host uses the syslog-ng utility, you need to add a source configuration block such as the example shown in Figure 14.5.
In addition to the source identification block, you also need to add filter, destination, and log configuration blocks to use the data from the source remote as required by your application.
1.
Log on as root to the BIG-IP system.
If everything is configured correctly, you should be able to get shell access to the remote logging host without being challenged for a password. (When you add the new identity key to the remote host's authorized_keys file, the key is used to authenticate the BIG-IP system.)
4.
Restart the syslog-ng utility by typing the following command:
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)