| Home Prev |  cOS Core 14.00.17 Administration Guide
|
Next |
|---|
The real-time performance of cOS Core can be monitored in a number of ways. They are:
Using the real-time monitoring functionality in InControl.
cOS Core real-time monitor alerts.
The cOS Core link monitor.
Monitoring through an SNMP client.
Hardware monitoring for specific hardware models.
Most cOS Core status and operational statistics are available to InControl for graphical display in a variety of display formats. This is achieved by InControl routinely polling cOS Core to gather the latest values of operational parameters. Note that the values from some subsystems, such as Web Content Filtering, are not available to InControl.
The following counters are available:
Throughput Statistics
CPU – The percentage load on the firewall CPU.
Forwarded bps - The number of bits forwarded through the firewall per second.
Forwarded pps - The number of packets forwarded through the firewall per second.
Buf use – Percentage of firewall packet buffers used.
Conns – The number of connections opened via Allow or NAT rules. No connections are opened for traffic allowed via FwdFast rules; such traffic is not included in this statistic.
Timers – The amount of timers used by the system.
Total mem usage – Percentage of the RAM memory that is currently being used.
Connection Rate Statistics
Conns opened per sec – The number of connections opened per second.
Conns closed per sec – The number of connections closed per second.
State Engine Statistics
ICMP Connections - Total number of ICMP connections.
UDP Connections - Total Number of UDP connections.
OPEN TCP - Total number of open TCP connections.
TCP SYN - Total number of TCP connections in the SYN phase.
TCP FIN - Total number of TCP connections in the FIN phase.
Other - Total number of other connection types such as IPsec.
TCP Buffer Statistics
Total small receive window usage - The number of small TCP receive windows currently being used.
Total large receive window usage - The number of large TCP receive windows currently being used.
Total small send window usage - The number of small TCP send windows currently being used.
Total large send window usage - The number of large TCP send windows currently being used.
Rule Usage Statistics
Each of the rules in a rule set has a counter associated with it which has the same name as the rule type.
These counters indicate the number of matches that have taken place for each rule. The rule sets that exist are:
Interface/VLAN/VPN Statistics
Rx/Tx Ring counters - Some drivers support plotting of FIFO-errors, saturation, flooding and other values depending on the driver.
Pps counters – The number of packets received, sent and summed together.
Bbs – The number of bits received, sent and summed together.
Drops – The number of packets received by this interface that were dropped due to rule set decisions or failed packet consistency checks.
IP errors – The number of packets received by this interface that were mutilated so badly that they would have had difficulty passing through a router to reach the Clavister firewall. They are therefore unlikely to be the result of an attack.
Send Fails – The number of packets that could not be sent, either due to internal resource starvation caused by heavy loading or hardware problems or congested half-duplex connections.
Frags received – The number of IP packet fragments received by this interface.
Frag reass – The number of complete packets successfully reassembled from the fragments received.
Frag reass fail – The number of packets that could not be reassembled, either due to resource starvation, illegal fragmentation, or just packet loss.
Active SAs - Current active number of SAs in use (VPN only).
Pipe Statistics
Total Pipe Statistics
Num users – The current number of users, as defined by the grouping settings of each pipe, being tracked in the pipes system. Note that this value corresponds to the number of users active in each time slice of 1/20th of a second, and not to the number of users having "open" connections.
Per Pipe Statistics
Num Users - The current number of users as above but on a per pipe basis.
Current bps – The current throughput of the pipe, in bits per second, per precedence and as a sum of all precedences.
Current pps – The current throughput of the pipe, in packets per second, per precedence and as a sum of all precedences.
Reserved bps – The current bandwidth allocated to each precedence; lower precedences are not allowed to use this bandwidth. Note that there is no reserved bandwidth for precedence 0, as it is simply given what is left of the total limit after all higher precedence reservations are subtracted.
Dyn limit bps – The current bandwidth limit applied to the respective precedences. This is related to the Reserved bps statistic, but is usually higher, as it shows how much bandwidth is left after higher precedence reservations have been subtracted from the total limit.
Delayed Packets – The number of times packets have been delayed as a result of a pipe, precedence, or pipe user having used up its allotted bandwidth. Note that one single packet may be delayed several times; if a pipe is really full, this count may exceed the number of packets actually passing through the pipe.
Dropped Packets – The number of packets dropped. Packets are dropped when cOS Core is running out of packet buffers. This occurs when excessive amounts of packets need to be queued for later delivery. The packet dropped is always the one that has been queued the longest time globally, which means that the connection suffering from packet loss will be the one most overloading the system.
Dyn User Limit bps – The current bandwidth limit per user of the pipe. If dynamic bandwidth balancing is enabled, this value may be lower than the configured per-user limits.
DHCP Server Statistics
Total Rejected requests – Total number of rejected packets (all rules).
Per Rule Statistics
Usage – Number of used IPs in the pool.
Usage (%) – Above value calculated as a percentage.
Active Clients – Number of currently active clients (BOUND).
Active Clients (%) – Above value calculated as a percentage.
Reject requests – Number of rejected requests.
Total number of leases – Total number of leases in the pool.
DHCP Relay Statistics
Total active relayed clients - Number of active relays in the Clavister firewall.
Ongoing transactions - DHCP transactions in the firewall.
Total rejected - Number of packets rejected by the DHCPRelay.
Active relayed clients - Number of active relays that uses this specific rule.
Rejected packets per rule - Number of packets rejected from clients using this rule.
General ALG Statistics
Total ALG sessions - Total number of ALG sessions.
Total connections - Total number of connections.
Total TCP Streams - Total number of TCP streams.
HTTP ALG, Web Content Filtering and Antivirus Statistics
Total requests - Total number of requests.
Total allowed - Total number allowed.
Total blocked - Total number of blocks.
URLs requested - Requests per URL category.
URLs allowed - Allowed requests per URL category.
URLs rejected - Rejected requests per URL category.
SMTP ALG DNSBL Statistics
Total Sessions Checked - Total number of URLs checked.
Total Sessions Spam - Total number of URLs found to be Spam.
Total Sessions Dropped - Total number of sessions dropped.
SMTP ALG DNSBL Server Statistics
For each DNSBL server:Total Sessions Checked - Total number of URLs checked by server.
Total Sessions Matched - Total number of URLs found to be Spam by server.
Total Failed Checks - Total number of checks where no response was received.
User Authentication Statistics
PPP – Number of PPP authenticated users.
HTTPAuth – Number of HTTP authenticated users.
Secure HTTP – Number of secure HTTP authenticated users.
XAUTH – Number of XAUTH authenticated users.
Link Monitor Statistics
PPP – Number of PPP authenticated users.
Packets lost/sec – Number of packets lost per second in polling.
Short Term Loss – % of short term packet loss.
Hosts Up – % of hosts available.
Packet Reassembly Statistics
Input Drops – Number of packet drops on input.
Load Factor – Loading of reassembly subsystem.
Allowed Buffers – Allowed buffers per connection.
IP Pools Statistics
Prepared – Number of prepared IP addresses.
Free – Number of addresses free.
Used – Number of addresses used.
Misses – Number of requests not met.
High Availability Statistics
Interface Queue – Size of the queue used for the sync interface.
Queue Usage Packets – Amount of the queue used in packets.
Queue Usage Bytes – Amount of the queue used in bytes.
Packets Sent – Number of packets sent on Sync.
Resent Packets – Number of packets resent on Sync.
A number of cOS Core statistical values can be monitored through the Real-time Monitoring feature. Real-time Monitor Alert thresholds can be specified in cOS Core for any of these monitored values so that they can have a maximum and/or a minimum numerical threshold.
Should a specified maximum or minimum threshold be crossed, cOS Core will automatically generate a log message which will be sent to all configured log receivers. All such log messages belong to the REALTIMEMONITOR message category which has the identity number 54.
The log message ID number will therefore take the form 054XXXXX where XXXXX represents the position of the statistic generating the event in the list of alert rules. A log message with identity 05400003, for example, means log ID number 3 in this category number of 054.
However, the administrator can customize the log message by specifying an integer value for the optional property Log Message ID. This value will then replace the statistic position value in the generated 054XXXXX ID.
Each Monitor Alert Rule consists of the following fields:Overview
The Link Monitor is a feature in cOS Core that allows monitoring of the connectivity to one or more IP addresses external to the Clavister firewall. This monitoring is done using standard ICMP "Ping" requests and allows cOS Core to assess the availability of the network pathways to these IP addresses. The administrator can select one of a number of actions to occur should a pathway appear to be broken for some reason.Link Monitor Actions
If sufficient replies are not received to link monitor polling, cOS Core makes the assumption that the common link to those IP address is down and can then initiate one of 3 configurable actions:A reconfigure operation.
A High Availability (HA) cluster failover.
An HA cluster failover followed by a reconfigure operation.
When multiple hosts are specified for a single Link Monitor object, more than 50% of the hosts have to be unreachable for the object's action to trigger. This is useful when it is the availability of the connection to the hosts that is important and not the hosts themselves. If it is the availability of a single host that is important then a Link Monitor object should be created that monitors only that host.
The Link Monitor Reconfigure is Different
The reconfigure that can be triggered by the link monitor has one special aspect to it. The link monitor reconfigure has the additional action of restarting all interfaces. This means that if there is a problem related to a particular Ethernet NIC, perhaps due to overload, then this can be cleared by interface initialization. This results in only a momentary delay in throughput while the reconfigure takes place.Link Monitor Uses
The Link Monitor is useful in two distinct scenarios:An external device develops an occasional problem with its link to the firewall and the physical link needs to be renegotiated. Such problems can occur sometimes with some older equipment such as ADSL Modems. For this scenario the action Reconfigure should be selected.
A reconfigure means that the cOS Core configuration will be reloaded. All connections and states are saved but reloading means all traffic is suspended for a short period and all interface links to external devices are renegotiated.
In an HA cluster setup, the link from the master to the external Internet (or other part of a network) can be continually monitored so that should the link fail, the slave will take over (assuming that the slave has a different physical connection to the monitored address). The action chosen for HA should be either Failover or Failover and reconfigure.
If the action option Reconfigure is chosen in an HA cluster, then the reconfigure will also cause a failover since it will temporarily suspend the master's operation while the reconfigure takes place and the slave will take over when it detects this inactivity. If reconfiguration with failover is desirable, it is better to select the option Failover and reconfigure since this performs the failover first and is nearly instantaneous with almost no traffic interruption. Having reconfiguration first is slower and can result in some traffic interruption.
To preserve all tunnels in a VPN scenario, it is best to choose the Failover option since a reconfiguration can cause some tunnels to be lost.
Link Monitoring with HA Clusters
The most common usage for link monitoring is in the HA cluster scenario described above. For HA clusters there is the additional link monitor option of Used Shared IP. If this is enabled then only the active cluster peer will send out pings. If it is disabled then both the active and inactive firewalls will send out pings. It is up to the administrator to decide if both master and slave ping the same IP address of if they ping different addresses (such as the router connected to the peer). However, note that pinging different addresses can only be achieved by selecting an IPvHA address in the link monitor.If it is important to not allow a failover during reconfiguration of the active unit in an HA cluster then the global advanced setting Reconf Failover Time should be set to a value which is neither too low or too high. The setting controls how long the inactive peer will wait for the active unit to reconfigure before taking over. Setting this value too low will mean the inactive firewall does not wait long enough. Setting the value too high could mean significant downtime if the active peer fails during reconfiguration and the inactive peer needs to take over.
More information on clusters can be found in Chapter 12, High Availability.
If the triggered link monitor action is a failover or failover and reconfigure, any IPsec tunnels are automatically closed and the tunnel SAs deleted at both ends. After the failover takes place the following will occur:If the IPsec tunnel was a LAN-to-LAN tunnel, it will be automatically reestablished provided traffic flows within the keepalive time specified for the tunnel.
Any IPsec tunnels from external clients will be lost and will not be reestablished automatically. The client must initiate a new connection.
Link Monitor Object Properties
A Link Monitor configuration object has the following properties:Action
Specifies which of the 3 actions described above cOS Core should take.
Addresses
This property specifies the IP address of one or more hosts to monitor. For multiple hosts, if half (50%) or more respond then there is assumed to be no problem. If less than half of multiple hosts do not respond, cOS Core assumes that there is a link problem. With a single host, it either responds or it doesn't so the 50% rule is not relevant.
A host is not used in this 50% calculation until cOS Core has been able to reach it at least once since the last cOS Core reconfiguration or full restart. This means that an unreachable host can be responsible for triggering an action once but not twice.
A group of three hosts, where one has been unreachable since the last reconfiguration, will therefore be treated as a two-host group until the third becomes reachable. This also means that if a problem triggers an action and the problem is not solved, cOS Core will not attempt to repeat the same action until the problem is solved and the hosts are again reachable.
Max Loss
A single host is considered unreachable if this number of consecutive ping responses to that host are not replied to. The default value is 7.
Initial Grace Period
Do not allow the link monitor to trigger an action for this number of seconds after the last reconfiguration. This avoids false positives during initial link negotiation. The default value is 45 seconds.
Ping Interval
The number of milliseconds between pings sent to hosts. The default value is 250.
Routing Table
This is the routing table used for looking up the route for the host IP addresses. The default is the main routing table.
Use Shared IP
This is only used when monitoring in a HA cluster. It allows the link monitor pings to be sent from the shared IP address instead of sending using the individual IPs of each unit. This is useful if public IPv4 addresses are not available for each peer in the cluster. This is discussed further in Section 12.6, Link Monitoring and HA.
Example 2.33. Link Monitor Setup
This example creates a Link Monitor object that will monitor the availability of the host found at the IPv4 address my_host. It is assumed this IPv4 address is already defined in the cOS Core address book.
The action for the monitor is HA Failover if it detects that the host is unavailable.
Command-Line Interface
Device:/> add LinkMonitor Action=HAFailover Addresses=my_hostInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Feature Availability
Certain Clavister hardware models allow the administrator to use the CLI to query the current value of various hardware operational parameters such as the current temperature inside the firewall. This feature is referred to as Hardware Monitoring.Configuring and performing hardware monitoring can be done either through the CLI or through the Web Interface. The feature is not available when cOS Core is running in a virtual environment.
Enabling Hardware Monitoring
The System > Device > Hardware Monitoring section of the Web Interface provides the administrator with the following settings for enabling hardware monitoring when it is available:Enable Sensors
Enable/disable all hardware monitoring functionality.
Default: Disabled
Poll Interval
Polling interval for the Hardware Monitor which is the delay in milliseconds between readings of hardware monitor values. Minimum value: 100, Maximum value: 10000.
Default: 500
To get a list of the current values from all available sensors, the following command can be used:Device:/> hwm -allDevice:/> hwm -aDevice:/> hwm -a
Name Current value (unit)
--------------- --------------------
SYS Temp = 44.000 (C) (x)
CPU Temp = 41.500 (C) (x)![[Note]](images/note.png) |
Note |
|---|---|
|
The "(x)" on the left side of the sensor listing indicates that the sensor is enabled. |
The -verbose option displays the current values plus the configured ranges. Some typical output from this command is shown below:
Device:/> hwm -a -v
4 sensors available
Poll interval time = 500ms
Name [type][number] = low_limit] current_value [high_limit (unit)
-----------------------------------------------------------------
SYS Temp [TEMP ][ 0] = 44.000] 45.000 [ 0.000 (C)
CPU Temp [TEMP ][ 1] = 42.000] 42.500 [ 0.000 (C)
AUX Temp [TEMP ][ 2] = 41.000] 43.000 [ 0.000 (C)
CPU Fan1 [FANRPM][ 1] = 6125.000] 6250.000 [ 0.000 (RPM)
Time to probe sensors: 2.980000e-05 seconds
Each physical attribute listed on the left is given a minimum and maximum range within which it should operate. When the value returned after polling falls outside this range, cOS Core automatically generates an HWM log message that is sent to the configured log servers. If an SNMP trap receiver is one of the receivers configured, an SNMP trap is sent.
The temperature sensor names should be interpreted as follows:
The SYS temperature should be used as an indication of the overall temperature inside the entire hardware unit.
The CPU temperature relates specifically to the unit's central processor which can be lower than the overall temperature due to the method of cooling.
The AUX sensor is found in some other arbitrary location and should be used as an alternative indication of the overall temperature. Hotspots can cause variations between this and the SYS temperature.
|
Note: Sensors can differ depending on hardware type |
|---|---|
|
Each hardware model can have a different set of sensors in different locations and with different operating ranges. The above output example and its values are for illustration only. |
Setting the Minimum and Maximum Range
The minimum and maximum values shown in the output from the hwm command are set through the Web Interface by going to System > Device > Hardware Monitoring > Add and selecting the hardware parameter to monitor. The desired operating range can then be specified.A sensor is identified in the Web Interface by specifying a unique combination of the following parameters:
Type
This is the type of sensor shown in the CLI output above and is presented as a list of choices in the Web Interface. For example, Temp.
Sensor
This is the number of the sensor as shown in the CLI output above. For example, the SYS Temp number is 0.
Name
This is the Name of the sensor as shown in the CLI output above. For example, SYS Temp.
Enabled
An individual sensor can be enabled or disabled used this setting. When enabled, an "(x)" is displayed next to the sensor in the output from the hwm command.
Controlling the Event Sending Frequency
The maximum frequency of log event generation when hardware monitoring values fall outside their preset range can be limited using the AlarmRepeatInterval setting in the LogSettings object. This setting is used because the monitored values are continuous.For example, to change the interval from the default of 60 seconds to a new value of 900 seconds, use the CLI command:
Device:/> set Settings LogSettings AlarmRepeatInterval=900This means that a new event message must now wait for 900 seconds after the previous one has been sent.
All the options for LogSettings can be found in Section 2.3.11, Advanced Log Settings.
Sensors for Clavister Products
The following are the available sensors for Clavister hardware products. Some of the products listed are no longer sold but they are included for completeness.Note that all fan speeds are given in RPM and all temperatures are given in degrees Centigrade.
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 65 |
| SysTemp | TEMP | 1 | 65 | 65 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| Right_CPUFan1 | FANRPM | 2 | 4000 | |
| Right_CPUFan2 | FANRPM | 0 | 4000 | |
| Right_CPUFan3 | FANRPM | 3 | 4000 | |
| Right_PSUFan | FANRPM | 1 | 4000 | |
| SysTemp1 | TEMP | 2 | 70 | |
| SysTemp2 | TEMP | 3 | 70 | |
| CpuTemp | TEMP | 512 | 80 | |
| PSU | GPIO | 256 | 1 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| Right_CPUFan1 | FANRPM | 2 | 4000 | |
| Right_CPUFan2 | FANRPM | 0 | 4000 | |
| Right_CPUFan3 | FANRPM | 3 | 4000 | |
| Right_PSUFan | FANRPM | 1 | 4000 | |
| Left_CPUFan1 | FANRPM | 6 | 4000 | |
| Left_CPUFan2 | FANRPM | 4 | 4000 | |
| Left_CPUFan3 | FANRPM | 7 | 4000 | |
| Left_PSUFan | FANRPM | 5 | 4000 | |
| SysTemp1 | TEMP | 2 | 70 | |
| SysTemp2 | TEMP | 3 | 70 | |
| CpuTemp | TEMP | 512 | 80 | |
| Right_PSU | GPIO | 256 | 0 | 2 |
| Left_PSU | GPIO | 257 | 0 | 2 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUFan | FANRPM | 1 | 1500 | |
| SysTemp | TEMP | 0 | 70 | |
| CpuTemp | TEMP | 256 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| Left_PSU | GPIO | 0 | 1 | |
| Right_PSU | GPIO | 0 | 1 | |
| SysTemp1 | TEMP | 256 | 0 | 70 |
| SysTemp2 | TEMP | 257 | 0 | 70 |
| SysFan1 | FANRPM | 256 | 1500 | 12800 |
| SysFan2 | FANRPM | 258 | 1500 | 12800 |
| SysFan3 | FANRPM | 260 | 1500 | 12800 |
| SysFan4 | FANRPM | 260 | 1500 | 12800 |
| CPUTemp1 | TEMP | 512 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| Left_PSU | GPIO | 0 | 1 | 0 |
| Right_PSU | GPIO | 1 | 1 | 0 |
| SysTemp1 | TEMP | 256 | 0 | 70 |
| SysTemp2 | TEMP | 257 | 0 | 70 |
| CpuTemp1 | TEMP | 260 | 0 | 80 |
| FanModule1_1 | FANRPM | 262 | 1500 | |
| FanModule1_2 | FANRPM | 263 | 1500 | |
| FanModule2_1 | FANRPM | 260 | 1500 | |
| FanModule2_2 | FANRPM | 261 | 1500 | |
| FanModule3_1 | FANRPM | 258 | 1500 | |
| FanModule3_2 | FANRPM | 259 | 1500 | |
| FanModule4_1 | FANRPM | 256 | 1500 | |
| FanModule4_2 | FANRPM | 257 | 1500 | |
| CpuTemp2 | TEMP | 512 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| CPUTemp | TEMP | 0 | 0 | 80 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| System Vcore Internal | VOLT | 0 | 0.494 | 1.744 |
| System 12V Internal | VOLT | 1 | 11.4 | 13.9 |
| System 5V Internal | VOLT | 2 | 4.8 | 5.8 |
| System 3.3V Internal | VOLT | 3 | 2.976 | 3.632 |
| System CMOS Battery | VOLT | 4 | 2.704 | 3.632 |
| System FAN Speed | FANRPM | 5 | 1400 | 14000 |
| System Temperature 1 | TEMP | 6 | 0 | 71 |
| System Temperature 2 | TEMP | 7 | 0 | 75 |
| System Temperature 3 | TEMP | 8 | 0 | 85 |
| CPU Core Temperature | TEMP | 9 | 0 | 85 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| System Vcore Internal | VOLT | 0 | 0.494 | 1.302 |
| System 3.3V Internal | VOLT | 1 | 3.135 | 3.465 |
| System 12V Internal | VOLT | 2 | 11.4 | 12.6 |
| System CMOS Battery | VOLT | 3 | 1.9 | 3.465 |
| System 5V Internal | VOLT | 4 | 4.75 | 5.25 |
| System FAN Speed | FANRPM | 5 | 1800 | 14000 |
| System Temperature 1 | TEMP | 6 | 0 | 80 |
| System Temperature 2 | TEMP | 7 | 0 | 80 |
| CPU Socket Temperature | TEMP | 8 | 0 | 95 |
| Sensor Name | Sensor Type | Sensor Number | Minimum Limit | Maximum Limit |
|---|---|---|---|---|
| PSU1 Installed | GPIO | 0 | 0 | 1 |
| PSU1 Power OK | GPIO | 256 | 0 | 1 |
| PSU1 Temperature | TEMP | 512 | 0 | 0 |
| PSU1 Fan Speed | FANRPM | 768 | 5000 | 14000 |
| PSU1 Output Voltage | VOLT | 1024 | 0 | 0 |
| PSU1 Output Current | CURR | 1280 | 0 | 0 |
| PSU1 Input Power | POWER | 1536 | 0 | 0 |
| PSU1 Output Power | POWER | 1792 | 0 | 0 |
| PSU2 Installed | GPIO | 2048 | 0 | 1 |
| PSU2 Power OK | GPIO | 2304 | 0 | 1 |
| PSU2 Temperature | TEMP | 2560 | 0 | 0 |
| PSU2 Fan Speed | FANRPM | 2816 | 5000 | 14000 |
| PSU2 Output Voltage | VOLT | 3072 | 0 | 0 |
| PSU2 Output Current | CURR | 3328 | 0 | 0 |
| PSU2 Input Power | POWER | 3584 | 0 | 0 |
| PSU2 Output Power | POWER | 3840 | 0 | 0 |
| System Vcore Internal | VOLT | 4096 | 0 | 1.744 |
| System 3.3V Internal | VOLT | 4097 | 0 | 0 |
| System 12V Internal | VOLT | 4098 | 11.5 | 13.0 |
| System CMOS Battery | VOLT | 4099 | 2.9 | 3.2 |
| System 5V Internal | VOLT | 4100 | 0 | 0 |
| System FAN1 Speed | FANRPM | 4101 | 6000 | 14000 |
| System FAN2 Speed | FANRPM | 4102 | 6000 | 14000 |
| System FAN3 Speed | FANRPM | 4103 | 6000 | 14000 |
| System Temperature 1 | TEMP | 4104 | 0 | 80 |
| System Temperature 2 | TEMP | 4105 | 0 | 80 |
| Air Intake Temp | TEMP | 4105 | 0 | 50 |
| CPU Temperature | TEMP | 4352 | 0 | 95 |
The System > Device > Hardware Monitoring section of the Web Interface provides the administrator with a number of settings related to the monitoring of available memory. Note that these settings are not available in virtual environments. The available settings are the following:
Memory Poll Interval
Memory polling interval which is the delay in minutes between readings of memory values. Minimum 1, Maximum 200.Default: 15 minutes
Memory Use Percentage
True if the memory monitor uses a percentage as the unit for monitoring, False if megabytes are used. Applies to Alert Level, Critical Level and Warning Level.Default: True
Memory Log Repetition
Should we send a log message for each poll result that is in the Alert, Critical or Warning level, or should we only send when a new level is reached. If True, a message is sent each time Memory Poll Interval is triggered. If False, a message is sent when a value goes from one level to another.Default: False
Alert Level
Generate an Alert log message if free memory is below this number of bytes. Disable by setting to 0. Maximum value is 10,000.Default: 0
Critical Level
Generate a Critical log message if free memory is below this number of bytes. Disable by setting to 0. Maximum value is 10,000.Default: 0
Warning Level
Generate a Warning log message if free memory is below this number of bytes. Disable by setting to 0. Maximum value 10,000.Default: 0
