Manual Chapter :
Troubleshooting Tools
Applies To:
Show Versions
ARX
- 6.3.0
| You can get a list of all alarm conditions with the show health command. |
| The show health time-skew command shows the clocking skew between the ARX and its network peers. |
| The ARX keeps its logs in a syslog file. You can access the syslog file by using show, grep, and tail. |
| Using SSH, you can run show commands from a remote host. |
Several of the ARXs Enterprise SNMP traps signal that an alarm condition is now active. This indicates a system failure, or that the system has crossed a resource threshold of some kind. If the condition clears or the system drops back below the threshold, another trap clears the alarm condition. From any mode, you can use the show health command to show all currently-active alarms on the system:
Refer to the ARX SNMP Reference for detailed information about any trap, including correction procedures.
bstnA(cfg)# show health
bstnA(cfg)# ...
After you have investigated an SNMP trap and resolved the underlying issue, you can dismiss the trap using the privileged-exec mode CLI command clear health. The command syntax is:
clear health trap
where trap is the trap or event name.
We recommend using NTP to synchronize time between the ARX and other network devices. For information on connecting the ARX to your NTP server(s), refer to Configuring NTP, on page 4-15 of the ARX® CLI Network-Management Guide.
From any mode, you can use the show health time-skew command to see the time skew between the ARX, its DCs, and its back-end filers:
show health time-skew [timeout seconds]
where timeout seconds (optional, 1-3600) specifies the maximum time to wait for responses from each server. The default is 3 seconds. The ARX often makes two or more connection attempts to each server, and this timeout applies to each attempt. Therefore, the command could take twice as long (or longer, in some cases) than the timeout you set here. Also, this timeout applies to each individual server, so the overall time for multiple servers may be longer. You can always use <Ctrl-C> to return to the CLI prompt before the command finishes.
bstnA(cfg)# show health time-skew
bstnA(cfg)# ...
The syslog (short for System Log) contains all log messages from the systems internal software. Processes add informational messages to this log as they run, as well as error messages of varying severities. For an alphabetical list of syslog messages, see the ARX Log Catalog.
bstnA(cfg)# show logs
You can use the tail command from any mode to view syslog messages as they are added to the log:
tail logs file-name follow
logs is required to specify the logs directory,
file-name (1-255 characters) identifies the file to tail, and
follow is required to follow the syslog as it grows.
Use tail logs syslog follow to view the syslog file. Use <Ctrl-C> to stop the tail output and return to the CLI prompt.
prtlndA> tail logs syslog follow
You can show the last few lines in the syslog file, without following any new syslog entries, by omitting the follow keyword:
file-name (1-255 characters) identifies the syslog file to tail, and
number-lines (optional, 1-4096) is the number of lines to show. By default, the command shows the last 24 lines in the file.
bstnA> tail logs syslog 5
Every log message originates from a log component (such as SCM_CLI in the sample above). A log component is a source of syslog messages, typically an internal process or group of processes. The table below is an alphabetical list of all log components, with a brief description and an indication of the board(s) where the software runs.
| utc (2009-05-13T11:05:44 in the example) is the time in UTC. |
| uuu (202) is the millisecond time fraction. |
| switch (bstnA) is the switch name. |
| slot-proc-board (1-1-SCM) is the chassis slot, processor number, and board type (ACM, ASM, SCM, or NSM). Use the show processors command for a list of all processors and their associated modules. |
| pid (29776) is the Process ID (PID). |
| ins (0) is the processs instance number. |
| sev (NOTE) indicates the message severity: DBG (debug) is the least severe, followed by INFO, NOTE, WARN, ERR, and CRIT (critical). |
| id (CLI_COMMAND) is the message-catalog ID, a unique ID for each log message. MSGn is an ID for an uncatologued message. The n is the severity of the message, from 7 (debug) down to 2 (critical). Refer to the ARX Log Catalog for an alphabetical list of log messages, sorted by their IDs. To view the documentation for a specific message, use the show documentation command (described later in the chapter). |
| msg (User admin: Command: bstnA# show nsck) is the message text itself. |
Syslog messages identify namespaces, volumes, and shares with numeric IDs. The syslog also uses numeric IDs to identify its file-history archives (recall Creating a File-History Archive). To correlate these IDs with the names used in the CLI, use the show id-mappings command:
bstnA(cfg)# show id-mappings
bstnA(cfg)# ...
Use the show logs command to page through the active syslog or one of the syslog backups:
show logs file-name
where file-name (1-1024 characters) is the name of the desired syslog file.
You can then use <Space> to step through the file one page at a time. Press q to quit out of the file.
bstnA(cfg)# show logs syslog
Use the grep command to apply a regular expression to the syslog as you page through it, viewing only the lines that contain a desired string:
pattern (1-255 characters) is the regular-expression pattern to search for in the syslog. The grep displays all lines containing this pattern.
| . matches any single character. |
| .* matches any string, including the null string. |
| [...] matches any one of the enclosed characters. |
| [a-z] matches any character in the sorted range, a through z. |
| \ matches the next character, even if it has special meaning (for example, \. matches a period instead of any character). |
| [^...] matches any character that is not enclosed. For example, [^0-9] matches any single character that is not a number from 0 to 9. |
logs is a required keyword; this specifies the logs directory, where the syslogs are stored.
file-name (optional, 1-255 characters) identifies one file to search. If you omit the file name, the CLI searches through all files in the logs directory. Use the show logs command to see a list of accessible log files.
bstnA(cfg)# grep shareOnline logs syslog
ignore is required, and
ignore-pattern (1-1024 characters) is a pattern to ignore. Surround this with quotes () if it contains any spaces.
bstnA(gbl)# grep shareOnline logs syslog ignore acct
The show and grep commands search from the beginning of the syslog file, starting with the oldest messages and moving toward the most-recent logs. To skip ahead to the most-recent logs, use the tail option at the end of the grep command:
tail is required, and
number-lines (1-4096) is the number of lines to show.
For example, the following grep command shows only the 10 most-recent matching lines in the active syslog:
bstnA(gbl)# grep shareOnline logs syslog tail 10
Many syslog messages (as well as messages from the CLI) have more-verbose documentation associated with them; you can access this additional documentation from the CLI. From any mode, use the show documentation command to view the documentation for a given message:
show documentation msg-catalog-id
where msg-catalog-id (1-255 characters) identifies the message. This ID appears with the message in both the syslog (recall the id field in each syslog message; see Syslog Syntax) and in CLI output.
bstnA(gbl)# grep RON_SPFD logs syslog
bstnA(gbl)# show documentation RON_SYSTEM_CLOCK_CHANGED
bstnA(gbl)# ...
You can save the syslog file off to a remote FTP server for further analysis. From priv-exec mode, use the copy logs command and specify the FTP server in a destination URL:
syslog-file identifies the syslog file to copy,
username:password@ (optional) is an FTP username and password (the default is set by the ip ftp-user command, as shown in Setting a Default FTP or SCP User),
ftp-site identifies the FTP server with an IP address or FQDN (for example, 172.16.88.3 or ftp.myftpsite.com), and
file is the chosen file name. Lead with an extra / if the path starts at the root of the server machine; for example, porthos//var/log/arx/syslog specifies /var/log/arx/syslog on server porthos. Omit the leading slash if the file is going to the home directory for username.
bstnA(cfg)# exit
bstnA# copy logs syslog ftp://juser:jpasswd@ftp.wwmed.com/syslog_5-6
bstnA# ...
syslog-file identifies the syslog file to copy,
username@ is a valid username at the remote host,
server identifies the SCP server with an IP address or FQDN (for example, 172.16.100.18 or deb1.mynet.com), and
file is the chosen file name at the remote server. Lead with a slash (scp-server:/file) if the file path is absolute. Without the slash, the path is presumed to start in the home directory for username.
accept-host-key (optional) tells the CLI to accept an unknown host key if offered by the SCP server. The host key authenticates the server; if the key is unknown, it is possible that an attacker has taken the servers hostname and/or IP address. Note that any SCP server is unknown if the switch has not had an SCP exchange with it since the switchs last reboot.
The CLI prompts for the usernames password. Enter a password that is valid at the remote site.
bstnA(cfg)# exit
bstnA# copy logs syslog scp://juser@rh1.wwmed.com:arx_syslog
Password: jpasswd
bstnA# ...
syslog-file identifies the syslog file to copy,
cifs | nfs is a required choice. This is the network protocol used to copy the syslog file into the ARX volume.
namespace (1-30 characters) identifies the destination namespace.
volume (1-1024 characters) is the volume name.
file-path (1-1024 characters) is the path from the volume root (above) to the destination file.
bstnA(cfg)# exit
bstnA# copy logs syslog cifs medarcv /rcrds admin
bstnA# ...
You can alternatively send the syslog file as an E-mail attachment. Before you use E-mail, you must configure the Simple Mail Transfer Protocol (SMTP) on the switch, starting with the smtp command in cfg mode: see the chapter on E-mail and SMTP in the ARX® CLI Reference.
e-mail-address (optional) identifies the recipient of the E-mail message (for example, myCoWorker@myco.com). If you omit this, it defaults to the E-mail recipient set with the cfg-smtp to command. Use a slash (/) to separate this from the file name.
file is the chosen file name.
bstnA(cfg)# smtp
bstnA(cfg-smtp)# mail-server email1.wwmed.com
bstnA(cfg-smtp)# from admin@acopia.wwmed.com
bstnA(cfg-smtp)# exit
bstnA(cfg)# exit
bstnA# copy logs syslog smtp://juser@wwmed.com/arx_syslog
bstnA# ...
From cfg mode, use the logging level command to change the logging level for one (or all) log components:
logging level component {critical | error | warning | notice | info | debug}
critical | error | warning | notice | info | debug chooses the logging level for the component. The critical level limits the component to critical log messages only, error allows both error and critical messages, and so on. Debug level is the most verbose; this causes the component(s) to issue every possible log message during their execution.
bstnA(cfg)# logging level TRANFS debug
bstnA(cfg)# ...
You can stop all log messages from a given component, or for all components. Use the disable keyword at the end of the logging level command:
logging level component disable
disable stops all logging from the component.
bstnA(cfg)# logging level POLICY_PDP disable
bstnA(cfg)# ...
Use the show logging levels command to see the logging levels for all log components:
bstnA(cfg)# show logging levels
show logging levels component
bstnA(cfg)# show logging levels POLICY
bstnA(cfg)# ...
The default logging level for all components is info. Use no logging level to revert to the default logging level:
no logging level {component | all}
where you must choose either a single component or all components. Refer to Log Components for a complete list of components.
bstnA(cfg)# no logging level all
bstnA(cfg)# ...
From cfg mode, use the logging destination command to add a server to the list of logging destinations:
target (1-80 characters) identifies an external server. This can be an IP address or, if you have a DNS lookups configured, a hostname. (To configure the switch for hostname lookups, see Configuring DNS Lookups, on page 4-31 of the ARX® CLI Network-Management Guide.)
udp | tcp (optional) chooses a transport protocol to reach the external server. This defaults to UDP if you omit it.
port port (optional, 1-65,535) selects a particular UDP or TCP port to receive the log messages. The default is port 514.
bstnA(cfg)# logging destination 172.16.202.8
bstnA(cfg)# logging destination 10.1.1.90 tcp port 9999
bstnA(cfg)# ...
Use the no form of the logging destination command to remove one log server from the list:
no logging destination target
where target (1-80 characters) identifies the server to remove. This can be an IP address or a hostname.
bstnA(cfg)# no logging destination 10.1.1.90
bstnA(cfg)# ...
By default, the log messages come from the out-of-band management interface (labeled MGMT on the switchs front panel). You have the option to change the source address to an in-band (VLAN) management interface, instead: this uses the client/server ports. (For more information on in-band management interfaces, see Configuring an In-Band (VLAN) Management Interface, on page 4-4 of the ARX® CLI Network-Management Guide.)
From cfg mode, use the management source command to change the source interface for outbound syslog messages:
management source vlan vlan-id
where vlan-id (1-4096 characters) identifies the VLAN. Use show interface vlan to list all configured VLANs and their management interfaces (see Listing all VLAN Management Interfaces, on page 4-6 of the ARX® CLI Network-Management Guide).
bstnA(cfg)# management source vlan 25
bstnA(cfg)# ...
To send syslog messages from the out-of-band management interface, the default, use the no form of the management source command:
prtlndA(cfg)# no management source
prtlndA(cfg)# ...
The management source mgmt command has the same effect:
bstnA(cfg)# management source mgmt
bstnA(cfg)# ...
To show all configured logging destinations, use show logging destination from any mode:
bstnA(cfg)# show logging destination
bstnA(cfg)# ...
The show system tasks command shows all running processes and the CPU and memory that each process is consuming. This is similar to the ps command on a Unix system, or the Task Manager on a Windows system. Invoke this command from any mode:
bstnA(cfg)# show system tasks
bstnA(cfg)# ...
From priv-exec mode, use the collect diag-info ftp command to collect all diagnostic data (except reports, which can make the file excessively large) and send it to an FTP site:
username[:password]@ (optional) is an FTP username and optional password (the default is the username/password set by the ip ftp-user command),
ftp-site identifies the FTP server with an IP address or FQDN (for example, 172.16.88.3 or ftp.myftpsite.com), and
file.tgz is the chosen file name. Lead with an extra / if the path starts at the root of the server machine; for example, athos//usr/local/diag_files.tgz specifies /usr/local/diag_files.tgz on server athos. Omit the leading slash if the file is going to the home directory for username.
The CLI prompts for a password if you enter the username without one. The CLI then prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming; prompts appear to show the progress of the operation as it occurs.
bstnA(cfg)# exit
bstnA# collect diag-info ftp://juser@arxftp.f5.com/acopia-diags.tgz
Password: jpasswd
bstnA# ...
username@ is a valid username at the remote host,
server identifies the SCP server with an IP address or FQDN (for example, 172.16.100.18 or deb1.mynet.com), and
file.tgz is the file name for the diagnostics data. Lead with a slash (scp-server:/file) if the file path is absolute. Without the slash, the path is presumed to start in the home directory for username.
accept-host-key (optional) tells the CLI to accept an unknown host key if offered by the SCP server. The host key authenticates the server; if the key is unknown, it is possible that an attacker has taken the servers hostname and/or IP address. Note that any SCP server is unknown if the switch has not had an SCP exchange with it since the switchs last reboot.
The CLI prompts for the usernames password. Enter a password that is valid at the remote site. Then the CLI prompts for confirmation before collecting diagnostics; enter yes to continue. As mentioned above, you should allow at least one minute for the collection process to complete.
bstnA(cfg)# exit
bstnA# collect diag-info scp://juser@rh1.wwmed.com:acopia-diags.tgz accept-host-key
Password: jpasswd
bstnA# ...
Some sites do not allow any FTP access to their data centers, and do not support SCP. For those sites, you can send the diagnostic data to a client-accessible volume on the ARX. You can use the nfs or cifs clause to send the output file to a given directory in a given volume:
cifs | nfs is a required choice. This is the network protocol used to transfer the diagnostics file to the ARX volume.
namespace (1-30 characters) identifies the destination namespace.
volume (1-1024 characters) is the destination-volume name.
dest-path (1-1024 characters) is the intended path from the volume root (above) to the diagnostics file. The directory you specify here must exist on the volume.
bstnA(cfg)# exit
bstnA# collect diag-info cifs medarcv /rcrds admin/collect.tgz
bstnA# ...
You can alternatively send the diagnostics information as an E-mail attachment. Before you use E-mail, you must configure the Simple Mail Transfer Protocol (SMTP) on the switch, starting with the smtp command in cfg mode: see the chapter on E-mail and SMTP in the ARX® CLI Reference.
In the same collect diag-info command, use the following syntax to send the diag-info as an E-mail attachment:
e-mail-address (optional) identifies the recipient of the E-mail message (for example, myCoWorker@myco.com). If you omit this, it defaults to the E-mail recipient set with the cfg-smtp to command. Use a slash (/) to separate this from the file name.
file.tgz is the chosen file name. The .tgz extension is required.
As with the FTP and SCP uploads, the CLI prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming; prompts appear to show the progress of the operation as it occurs.
bstnA(cfg)# smtp
bstnA(cfg-smtp)# mail-server email1.wwmed.com
bstnA(cfg-smtp)# from admin@acopia.wwmed.com
bstnA(cfg-smtp)# exit
bstnA(cfg)# exit
bstnA# collect diag-info smtp://juser@wwmed.com/acopia-diags.tgz
bstnA# ...
collect diag-info file.tgz
where file is the chosen file name. You must use a .tgz extension on the end of the file name. The file is stored in the diag-info directory.
The CLI prompts for confirmation before overwriting any previously-collected diag-info files. Answer yes to continue. As stated above, the collection process can be time-consuming; allow at least one minute for the collection process to finish.
bstnA(cfg)# exit
bstnA# collect diag-info juser-ns-wwmed.tgz
bstnA# ...
Use the show diag-info command to view the directory listing with the new diag-info file:
bstnA# show diag-info
bstnA# ...
You can run the collection process in the background while you continue to enter more CLI commands. To accomplish this, use the optional async keyword before the URL:
collect diag-info destination async
destination can be any of the formats defined above for FTP, SCP, SMTP, an ARX volume, or a local file, and
async makes the collection process asynchronous.
The CLI prompts for confirmation; answer yes to continue. With the async option, the CLI displays a report name and then returns. You can use the tail reports report-name follow command to follow the collection process, or you can enter other CLI commands.
bstnA(cfg)# exit
bstnA# collect diag-info ftp://juser:jpasswd@arxftp.f5.com/acopia-diags.tgz async
bstnA# ...
collect {diag-info | config | cores | logs | reports | state | capture | all} destination [async]
diag-info collects everything except reports, as described above.
config collects the configuration database, database logs, and the output from show running/global config.
cores gathers any core-dump files on the system, along with all shared-object libraries used by the system.
logs assembles the syslog, the procdat log (process data; a more-detailed log file for diagnosis by engineers), upgrade and installation logs, disk-usage logs, Kerberos state files, and logs from the systems service manager.
reports chooses all reports. (As mentioned above, these are omitted from the diag-info option because they can be excessively large at some installations.)
state collects individual log files from every processor in the switch, three system log files (syslog, procdat, and traplog), a chronological list of all CLI commands used since the switch booted, and the output from a series of useful show commands.
capture assembles all packet-capture files, which you can list with the show capture command. You can use a CLI command to capture IP traffic in a file for diagnostic purposes, as described in a later chapter. This command can send the capture file(s) to F5 for detailed examination.
all collects all information, including all reports. The diag-info option omits reports because they can be excessively large on some switches.
destination is either a local file name or any of the upload formats described above.
async (optional) makes the collection process asynchronous.
As shown earlier, the CLI prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming, depending on system state and the option that you have chosen; prompts appear to show the progress of the operation as it occurs.
bstnA(cfg)# exit
bstnA# collect state ftp://arxftp.f5.com/sys-state.tgz
bstnA# ...
start-time start [utc] (optional) establishes a start time. If omitted, the command collects all of its logs up to the end-time.
| start is a date and time. Enter this in one of two formats: mm/dd/yyyy:HH:MM:SS (designed for manual entry) or yyyy-mm-ddTHH:MM:SS (the time format found in the log files). |
| utc (optional) indicates that the start is UTC instead of local time. Without this, the start is assumed to be in local time, as established by the clock timezone command. This is intended for a copy-and-paste from a log file. (All time stamps in the log files are in UTC.) |
end-time end [utc] (optional) establishes an end time for the collected logs. If omitted, the command collects all of its logs after the start-time. This has the same options as described above.
destination is either a local file name or any of the upload formats described above.
async (optional) makes the collection process asynchronous.
As with a full collection, the CLI prompts for confirmation before collecting the logs. Answer yes to continue. The collection process can be time-consuming, depending on system state and the options that you have chosen; allow at least one minute for the process to finish.
bstnA(cfg)# exit
bstnA# collect logs start-time 05/06/2008:09:30:00 end-time 05/06/2008:12:30:00 smtp://juser@wwmed.com/mornLogs.tgz
bstnA# ...
Important: You must configure DNS and SMTP before you set up this data gathering mechanism. For instructions on setting up DNS, refer to the ip name-server command in the ARX® CLI Reference. For instructions on setting up SMTP, refer to the smtp command in the same manual.
From gbl mode, use the auto-diagnostics command to begin configuring the schedule for this regular data collection:
bstnA(gbl)# auto-diagnostics
The first step in setting up auto-diagnostic collection is assigning a schedule for it. To create a schedule, use the gbl schedule command (refer to Appendix 12, Creating a Policy Schedule of the ARX® CLI Storage-Management Guide for details). To apply a schedule to auto-diag collection, use the schedule command in gbl-auto-diag mode:
schedule name
where name (1-64 characters) identifies the schedule. Use the show schedule command to list all schedules.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# schedule daily4am
| show namespace all |
| show arp all |
| show statistics namespace ... fastpath all fastpath |
| show policy details |
| show cifs-service user-sessions all summary |
| show active-directory status detailed |
| show statistics filer detailed |
You can use the additional-command operation to add more show commands to this collection:
additional-command "show-command-string"
where show-command-string is the additional show command (128-byte limit) to add to the auto-diag collection. This command must start with the keyword, "show," and must be accessible from any CLI mode. Surround the string with quotation marks ("") if it contains any spaces.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# additional-command "show global service"
bstnA(gbl-auto-diag)# additional-command "show share status"
| show arp all |
Use the command no additional-command to remove a user-added show command from future auto-diagnostic collections. This removes only the specified additional command, not any of the default commands listed in the previous section. The command syntax follows:
no additional-command "show-command-string"
For example, this command sequence removes the extra show command show share status from the auto-diagnostics collection at the "bstnA" switch:
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# no additional-command "show share status"
You can use the mail-to command to add additional recipients for the collected E-mails. Unlike the collection for F5 Support, the E-mail attachment for these recipients is not encrypted. The ARX encrypts the collected information for F5 Support because it is likely to traverse the Internet:
mail-to recipient
where recipient is the E-mail address (128-byte limit) for someone to receive the collected diagnostics.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# mail-to juser@wwmed.com
bstnA(gbl-auto-diag)# mail-to jsmith@wwmed.com
Use no mail-to to remove one E-mail recipient from the auto-diagnostics list:
no mail-to recipient
where recipient (1-768 characters) is the E-mail address to remove.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# no mail-to jsmith@wwmed.com
You can display the current auto-diagnostics configuration by executing the show auto-diagnostics command. An example of the output from this command follows:
Type the privileged-exec mode CLI command auto-diagnostics test local to send an unencrypted auto-diagnostics mail test message to the Email addresses configured with the gbl-auto-diag mode mail-to command. No mail is sent to F5 Networks when this command is executed.
You can use SSH (the Secure SHell command) from a remote machine to run any show command at an ARX. Earlier chapter describe how to run various snapshot commands and/or a volume restore through SSH; recall Running Snapshot Operations from a Remote Host and Running the Restore from a Remote Host. You use the same ssh syntax to run show commands:
admin-user is the username for a valid administrative account at the ARX (use show users to list all of them, as shown in Listing All Administrative Users, on page 2-14 of the ARX® CLI Network-Management Guide),
mip is a management-IP address for the ARX (use show interface mgmt to show the out-of-band management interface, or show interface vlan to show all in-band management interfaces), and
show-command is a show command to run remotely. Surround this with quotation marks () if it contains any spaces.
The output of the show command appears in the local shell. For example, this command sequence runs from a Unix machine named mgmt17. The command runs show processors on bstnA, a remote ARX:
juser@mgmt17:~$ ssh admin@10.1.1.7 show processors
For example, the following command shows a namespace named test ns. The show namespace command requires quotes around test ns because it has a space in it.
juser@mgmt17:~$ ssh admin@10.1.1.7 show namespace %22test ns%22
Note: The snapshot remove command must remove the oldest snapshot before it removes any other snapshots. Without this restriction, file changes may be lost when a snapshot in the middle is removed. If a snapshot is removed while it is being used, the client will be notified, and it should rescan the files.
Executing the gbl-ns-vol mode CLI command notification rule creates a notification rule object and enters gbl-ns-vol-ntfy mode for defining the rule. This mode provides the following CLI commands:
| enable, which activates the current snapshot rule. |
notification rule name
where name is the notification rule to be defined or edited.
The data collected by the statistics monitor resides on each switch at /acopia/var/log/stats-logs as comma-separated value (CSV) files that can be opened in spreadsheet applications such as Microsoft Excel. These files can be copied off the switch as desired for further examination and for consultation with F5 support staff as necessary. One way of doing this is to use the collect stats-logs CLI command to gather the statistics monitoring files and write them to a location from which they can be shared easily.
Note: The various clear statistics CLI commands will reset these statistics and will be indicated by a reset marker in the log file. Clearing the global configuration will clear the statistics monitor data; if you wish to retain this data, make certain to copy it off the switch prior to clearing the global configuration.
Execute the show stats-monitor CLI command to display the current statistics monitor configuration:
Note: All commands related to configuring the statistics monitor or accessing the log files that it generates are in terminal beta mode. You must execute the terminal beta CLI command in order for any of these commands to be available.
After youve activated terminal beta mode, type stats-monitor in global configuration mode to enter gbl-stmon mode. Use this mode to access the statistics monitor log files, and to configure the statistics monitors sampling and notification behaviors.
To change the data sampling interval, use the sampling interval CLI command in gbl-stmon mode to specify the number of seconds between sampling intervals. This can range from a minimum of 30 to a maximum of 86,400 (one day).
Use the notify command in gbl-stmon mode to enter gbl-stmon-nfy mode for configuring event notification for a CIFS service, NFS service, or filer share. This controls when notification is sent because recent data is anomalous in the context of similar performance statistics used to calculate the moving average for the relevant parameter.
This causes you to enter a submode corresponding to the type of service that you specified, such as gbl-stmon-nfy[~cifs-service] if you executed notify cifs-service. If you specify filer-share, you must also specify cifs or nfs. Within each submode, you can use the commands metric, moving-average, and trap to configure the corresponding event notification parameters for that service type.
moving-average errors threshold <percentage value>
moving-average response-time threshold <percentage value>
The Email group, stats-monitor, can be configured for trap notification for the following events:
| filer-slow-clear: Filer share slowness is cleared. |
| filer-slow-raise: A filer share is slow. |
| service-slow-clear: Service slowness is cleared. |
| service-slow-raise: A service is slow. |
| filer-errors-clear: Filer errors are normal. |
| filer-errors-raise: Filer errors exceed the notificiation thresholds. |
| service-errors-clear: Service errors are normal. |
| service-errors-raise: Service errors exceed the notification thresholds. |
For each event, the notification threshold is configured according to the number of occurrences within a specified time interval, as is done for events for other Email groups. Refer to the ARX® CLI Reference for complete details of the group stats-monitor command.
List the statistics monitor log files that are present on the switch by executing the show stats-logs CLI command.
| cifs-service: This file type contains data plane CIFS service statistics, with services identified by their FQDN. |
| cifs-service-auth: This file type contains CIFS service authentication statistics. The services are identified by their FQDN. |
| cifs-share: This file type contains data plane and control plane CIFS filer share statistics, with shares identified by their namespace, volume, and share name in the ARX configuration. |
| cifs-work-queue: This file type contains CIFS work queue statistics. Work queues are identified by their volume group ID. |
| domain-controller: This file type contains domain controller statistics. Domain controllers are identified by their IP address. |
| metadata: This file type contains metadata statistics; objects in this file are identified by their namespace and volume. |
| metalog: This file type contains metalog statistics; objects in this file are identified by their volume group ID. |
| migration: This file type contains migration statistics. Objects in this file are identified by their namespace and volume. |
| nfs-service: This file type contains data plane NFS service statistics, with services identified by their FQDN. |
| nfs-share: This file type contains data plane and control plane NFS filer share statistics, with shares identified by their namespace, volume, and share name in ARX configuration. |
