SNMP Technical Documentation
From UntangleWiki
Contents |
Untangle SNMP Support
Introduction
This document describes the manner in which an Untangle Gateway (UTM) supports access by SNMP via an SNMP management application. It assumes the reader has a basic understanding of SNMP and therefore does not provide any SNMP background information.
Overview
Simple Network Management Protocol (SNMP) is a protocol used to communicate with network-oriented devices for the purpose of querying information about such devices and to manipulate and configure them in a standardized, homogeneous manner. Untangle intends to provide support for SNMP access to UTMs in order to gather performance statistics; we do not intend to support configuration of UTMs via SNMP (the 'set' operation specifically.)
Design
Summary
UTM SNMP support is accomplished as follows:
- The UTM host SNMP agent is extended via an external program of our creation, namely uvmsnmp.sh. When information is requested about the devices mapped below our MIB-tree root, uvmsnmp.sh is called by the SNMP agent and it initiates the SNMP operation.
- uvmsnmp.sh is a shell script that invokes the NUCLI client in command line mode, passing to it the effective filter node type, if any, and the effective SNMP operation and OID.
- NUCLI client processes the arguments passed to it and sends them along to the NUCLI server for processing. If all is correct, NUCLI server returns SNMP formatted information as a function of the effective SNMP operation; which will be either a get or getnext, since we don't support set.
MIB & OID
SNMP organizes devices to be managed in a tree structured "data base" called the Management Information Base, or "MIB". Nodes of the MIB tree, called objects, are identified by a so-called Object Identifier, or "OID". An OID is a string of numbers separated by periods/dots, where each number specifies which sibling of a sub-tree to take to get to the information about a node in question. Each number in an OID actually has a human readable string name but we won't elaborate on that here. Although any device can use any part of the MIB tree it wants, a well behaved device maps itself to a portion of the MIB tree that has been assigned to it by the governing body IANA. Untangle's MIB-tree root is .1.3.6.1.4.1.30054 This is the permanent root of the Untangle MIB tree and all UVM node information is mapped below this. For example, .1.3.6.1.4.1.30054.1 is the root of the MIB sub-tree for Web Filter nodes, etc. Here's a legend of the Untangle MIB tree as it exists today:
- .1.3.6.1.4.1.30054. - Our sub-tree root
- .1.3.6.1.4.1.30054.0. - Statistics for UVM (not including filter node specific - NOT YET IMPLEMENTED)
- .1.3.6.1.4.1.30054.1. - Statistics for web filters
- .1.3.6.1.4.1.30054.1.0 - Aggregated statistics for all installed web filters
- .1.3.6.1.4.1.30054.1.X - Statistics for EACH installed web filter X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.2 - Statistics for firewalls
- .1.3.6.1.4.1.30054.2.0 - Aggregated statistics for all installed firewalls
- .1.3.6.1.4.1.30054.2.X - Statistics for EACH installed firewall X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.3 - Statistics for attack blockers
- .1.3.6.1.4.1.30054.3.0 - Aggregated statistics for all installed attack blockers
- .1.3.6.1.4.1.30054.3.X - Statistics for EACH installed attack blocker X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.4 - Statistics for protocol filters
- .1.3.6.1.4.1.30054.4.0 - Aggregated statistics for all installed protocol filters
- .1.3.6.1.4.1.30054.4.X - Statistics for EACH installed protocol filter X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.5 - Statistics for IPS
- .1.3.6.1.4.1.30054.5.0 - Aggregated statistics for all installed protocol filters
- .1.3.6.1.4.1.30054.5.X - Statistics for EACH installed protocol filter X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.6 - Statistics for Phish blocker
- .1.3.6.1.4.1.30054.6.0 - Aggregated statistics for all installed protocol protocol
- .1.3.6.1.4.1.30054.6.X - Statistics for EACH installed protocol protocol X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.7 - Statistics for Router
- .1.3.6.1.4.1.30054.7.0 - Aggregated statistics for all installed routers
- .1.3.6.1.4.1.30054.7.X - Statistics for EACH installed router X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.8 - Statistics for Spyware blocker
- .1.3.6.1.4.1.30054.8.0 - Aggregated statistics for all installed Spyware blockers
- .1.3.6.1.4.1.30054.8.X - Statistics for EACH installed Spyware blocker X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.9 - Statistics for Virus blocker
- .1.3.6.1.4.1.30054.9.0 - Aggregated statistics for all installed Virus blockers
- .1.3.6.1.4.1.30054.9.X - Statistics for EACH installed Virus blocker X, ie, 1, 2, 3...
- .1.3.6.1.4.1.30054.10 - Statistics for Spam blocker
- .1.3.6.1.4.1.30054.10.0 - Aggregated statistics for all installed Spam blockers
- .1.3.6.1.4.1.30054.10.X - Statistics for EACH installed Spam blocker X, ie, 1, 2, 3...
See Interpretation_of_Output for a list of Filter Node statistics as displayed under a specific TID subtree of a specific node type.
SNMP Agent
In order for a device to be accessible via SNMP, the SNMP agent running on the device's host system must be extended in some way so the device can be communicated with by the agent. There are several ways to accomplish this: via an external program or by a pre-compiled C module (AKA "MIB module") that is loaded into the SNMP agent. Because access to a UVM is via Java, the C MIB module approach is not viable so we've taken the external program approach.
To extend an SNMP agent via an external program, a 'pass' entry is made in the agent's snmpd.conf file. The pass entry specifies the OID of a MID sub-tree to be managed by the external program, the external program to be run and any arguments to be passed to the program. When the SNMP agent is asked for information about this OID it passes the request off to the external program to be fulfilled. The external program is then responsible for functioning as a well behaved MIB module stand-in and must return results in a required format, depending on the SNMP operation in effect. Here is an example of a pass entry from our snmpd.conf implementation:
pass .1.3.6.1.4.1.30054.1 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh webfilter
Here's a break down of our pass entry:
- .1.3.6.1.4.1.30054.1 -- the MIB sub-tree for UVM Web Filters
- /bin/sh -- the external program to run, in this case a Borne Shell
- /bin/sh /usr/share/untangle/bin/uvmsnmp.sh -- an argument to the external program, which happens to be the shell script which will actually initiate the SNMP request.
- webfilter -- an argument to /bin/sh which is in turn passed to the uvmsnmp.sh script, which is in turn passed on the the program run by the uvmsnmp.sh script.
In review: when an SNMP application requests information about OID .1.3.6.1.4.1.30054.1 a Borne Shell is executed, which runs our uvmsnmp.sh script, which in turn runs another program, namely the NUCLI client, to initiate the SNMP request. It is in fact, ultimately, the NUCLI server, interacting with the Web Filter Nodes of the UVM, which fulfills the SNMP request: /bin/sh, uvmsnmp.sh and NUCLI client are just intermediaries that facilitate the process.
For further details about the external program "uvmsnmp.sh" see UTSNMPSupport#NUCLI_Stats. For further details about the snmpd.conf file we'll be using when we deploy a UTM with SNMP support, see UTSNMPSupport#snmpd.conf.
NUCLI Stats
The uvmsnmp.sh is a script that launches the NUCLI client passing to it the massaged parameters passed into it by the SNMP agent. Let's take a look at the script and dissect it:
#!/bin/bash
if [ ${#UVM_ROOT} != 0 ] ; then
NUCLI_ROOT=${UVM_ROOT}/../../pkgs/untangle-cli-client/files
else
NUCLI_ROOT=""
fi
/usr/bin/ruby -X ${NUCLI_ROOT}/usr/share/untangle-cli-client/src -- ./client.rb -h localhost -c $1%20snmp%20$2%20$3
- sha-bang -- identifies program to run this script with if it were launched directly.
- Determine path to NUCLI client (in case we're running in a developer build.)
- Invoke the NUCLI client with Ruby passing to it the host to connect to and the command to run. In the example "pass" statement we reviewed above, the command to execute (as passed to the -c NUCLI client option) would be: webfilter%20snmp%20-n%20.1.3.6.1.4.1.30054.1 (the %20 being the HTTP character encoding of a space character - this ensures that the -c option's argument is maintained as a single command line option argument when passed to the NUCLI client.)
Usage
snmpwalk
The snmpwalk program can be used to query a OID or MIB sub-tree. To use it to query UVM statistics follow these steps:
- Make sure you have SNMP installed on your system, that your snmpd.conf file is configured as shown in UTSNMPSupport#snmpd.conf and snmpd is running.
- Make sure your UVM is running as well as the Untangle (Swing) Client.
- In the Untangle Client go to Remote Admin and enable outside access and then SNMP monitoring: make sure you fill in all SNMP monitoring fields and MOST IMPORTANTLY that the "Community" field is set to 'untangle'.
- Create a rack and install in it a firewall and web filter.
- Check out the NUCLI code base as described in NUCLIDesignSpecification#Testing
- Edit your checked out copy of pkgs/untangle-cli-server/files/uvmsnmp.sh and adjust the path argument of the -X option to match where your code was checked out, if necessary.
- sudo or su to root and execute snmpwalk as follows:
/usr/bin/snmpwalk -t 10 -v 1 -c untangle localhost .1.3.6.1.4.1.30054
If everything is correct you should see output as follows:
... <snip> SNMPv2-SMI::enterprises.30054.1.4.1 = STRING: "untangle-node-webfilter" SNMPv2-SMI::enterprises.30054.1.4.2 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.4.3 = INTEGER: 6 SNMPv2-SMI::enterprises.30054.1.4.4 = INTEGER: 6 SNMPv2-SMI::enterprises.30054.1.4.5 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.4.6 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.4.7 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.4.8 = INTEGER: 66567 SNMPv2-SMI::enterprises.30054.1.4.9 = INTEGER: 7615 SNMPv2-SMI::enterprises.30054.1.4.10 = INTEGER: 5927 SNMPv2-SMI::enterprises.30054.1.4.11 = INTEGER: 22 SNMPv2-SMI::enterprises.30054.1.4.12 = INTEGER: 11028815 SNMPv2-SMI::enterprises.30054.1.4.13 = INTEGER: 33 SNMPv2-SMI::enterprises.30054.1.4.14 = INTEGER: 11089471 SNMPv2-SMI::enterprises.30054.1.4.15 = INTEGER: 7604 SNMPv2-SMI::enterprises.30054.1.4.16 = STRING: "Thu Dec 13 12:18:43 PST 2007" SNMPv2-SMI::enterprises.30054.1.4.17 = STRING: "Thu Dec 13 12:18:43 PST 2007" SNMPv2-SMI::enterprises.30054.1.4.18 = STRING: "Thu Dec 13 12:43:54 PST 2007" SNMPv2-SMI::enterprises.30054.1.4.19.1 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.2 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.3 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.4 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.5 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.6 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.7 = Counter32: 11 SNMPv2-SMI::enterprises.30054.1.4.19.8 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.9 = Counter32: 11 SNMPv2-SMI::enterprises.30054.1.4.19.10 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.11 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.12 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.13 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.14 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.15 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.4.19.16 = Counter32: 0 SNMPv2-SMI::enterprises.30054.2.0.1 = STRING: "untangle-node-firewall" SNMPv2-SMI::enterprises.30054.2.0.2 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.2.0.3 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.2.0.4 = INTEGER: 12 SNMPv2-SMI::enterprises.30054.2.0.5 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.2.0.6 = INTEGER: 0 <snip> ... End of MIB
Note that since we walked starting from the UTM MIB sub-tree root node', i.e, .1.3.6.1.4.1.30054, we get back information about all UTM objects mapped below our root node. If instead you wanted to review the SNMP information for a specific UVM node type, e.g., just web filters, append that node's type ID to the OID passed into snmpwalk. For web filters, the node type ID is 1:
/usr/bin/snmpwalk -t 10 -v 1 -c untangle localhost .1.3.6.1.4.1.30054.1
Or, if you just wanted to query a single node, append the node's type ID followed by the node's TID, e.g. 32:
/usr/bin/snmpwalk -t 10 -v 1 -c untangle localhost .1.3.6.1.4.1.30054.1.32
Or, if you just wanted to query a single value, append the node type ID, the node TID and the number of the item:
/usr/bin/snmpget -t 10 -v 1 -c untangle localhost .1.3.6.1.4.1.30054.1.32.3
Interpretation of Output
For Untangle 5.1, our SNMP support is limited to querying UVM node statistics and that is what you see in the snmpwalk output sample above. It appears that the majority of UVM nodes expose the same set of statistics and those statistics are mapped to OIDs as follows: Our-MIB-Root.node-type-ID.TID.stat-id, e.g. .1.3.6.1.4.1.30054.1.32.3. For a list of node-type-IDs see UTSNMPSupport#Node_Type_ID_Table. For a legend of each node's custom counters see UTSNMPSupport#Filter_Node_Custom_Counter_Legend. Here is the mapping of stat-ids to UVM node statistics:
| Stat ID | UVM Node Type |
|---|---|
| .1 | UVM Node Type Name |
| .2 | tcpSessionCount |
| .3 | tcpSessionTotal |
| .4 | tcpSessionRequestTotal |
| .5 | udpSessionCount |
| .6 | udpSessionTotal |
| .7 | udpSessionRequestTotal |
| .8 | c2tBytes |
| .9 | c2tChunks |
| .10 | t2sBytes |
| .11 | t2sChunks |
| .12 | s2tBytes |
| .13 | s2tChunks |
| .14 | t2cBytes |
| .15 | t2cChunks |
| .16 | startDate |
| .17 | lastConfigureDate |
| .18 | lastActivityDate |
| .19.[1...16] | Node-Type Specific Custom Counters |
Filter Node Custom Counter Legend
In the above section UTSNMPSupport#Interpretation_of_Output, each set of statistics reported includes a set of 16 custom counters, i.e., .19.1, .19.2, ..., .19.16. Here is a legend of these counters for each UVM node type, numbered by custom counter index number, i.e., 1. corresponds to .19.1, 2. to .19.2, etc.
- Virus
- Scan Counter = 7
- Block Counter = 8
- Pass Counter = 9
- Remove Counter = 10
- Web Filter
- Scan Counter = 7
- Block Counter = 8
- Pass Counter = 9
- Open VPN
- Block = 7
- Pass = 8
- Connect = 9
- IPS
- Scan Counter = 7
- Detect = 8
- Block = 9
- Protocol Filter
- Scan = 7
- Detect = 8
- Block = 9
- Router
- Block = 7
- NAT = 8
- Redirect = 9
- DMZ = 10
- Spyware
- Scan = 7
- Block = 8
- Pass = 9
- Firewall
- Block = 7
- Pass = 8
- Spam
- Pass = 7
- Block = 8
- Mark = 9
- Quarantine = 10
- Phish
- Scan Counter = 7
- Block Counter = 8
- Pass Counter = 9
- Remove Counter = 10
- Attack
- Has no custom counters.
Node Type ID Table
Here is the list of UVM node types and their corresponding SNMP IDs, i.e., the node type number in a UVM SNMP OID (1.3.6.1.4.1.30054.node-type-number.stat-id)
| UVM Node Type | SNMP ID |
|---|---|
| Web Filters | 1 |
| Firewalls | 2 |
| Attack Blockers | 3 |
| Protocol Filters | 4 |
| IPSs | 5 |
| Phish Blockers | 6 |
| Routers | 7 |
| Spyware Blockers | 8 |
| Virus Blockers | 9 |
| Spam Blockers | 10 |
| Dual Virus Blockers | 11 |
NMS Integration
UTM SNMP support is designed for easy integration with SNMP managers such as popular 3rd party NMS systems. As shown above, UVM statistics are reported via SNMP on a per filter node basis. This provides a fine granularity report but leads to a couple of issues when one considers integrating with an NMS: (1) in general, a sys-op is interested in statistics over all filter nodes of a certain type installed on a UVM, rather than the statstics of just one of the filters of that type. (2) Because the TID of a filter node is determined when it is installed in a UVM, the TIDs of like filter nodes will definitely vary rack to rack and machine to machine, as nodes are added and removed from UVMs over time. Hence, setting up NMS monitoring rules over multiple racks, over multiple UTM's can be tedious and perhaps error prone because, say, the TID for the webfilters on one system will not be the same as on another system and may in fact change if the webfilter is removed and then readded to a UVM. To address these two issues, the UVM SNMP statistics reporting includes a special OID for each filter node type: the so-called "TID zero" OID. The MIB-tree for TID zero (TID0) is a complete set of node statistics that is the sum total (aggregation) of all of the statistics of all filter nodes of a certain type installed in one UVM. For example, the OID 1.3.6.1.4.1.30054.1 is the MIB sub-tree root of statistics for all webfilter nodes and the statistics for each node are reported in sub-trees rooted there, e.g., 1.3.6.1.4.1.30054.1.20 would hold the stats for the webfilter node with TID '20'. Now then, OID 1.3.6.1.4.1.30054.1.0 is the MIB sub-tree for the sum total of each web filter node's statistics over all installed web filter nodes. That is to say, if we have 5 racks on a UVM each with a webfilter installed then OID 1.3.6.1.4.1.30054.1.0.2 would be the sum total of all 5 webfilter's TCP Session Count statistics. For example:
snmpwalk -v 1 -c untangle localhost 1.3.6.1.4.1.30054.1.0 [root @ kelly2] SNMPv2-SMI::enterprises.30054.1.0.1 = STRING: "untangle-node-webfilter" SNMPv2-SMI::enterprises.30054.1.0.2 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.0.3 = INTEGER: 6 SNMPv2-SMI::enterprises.30054.1.0.4 = INTEGER: 6 SNMPv2-SMI::enterprises.30054.1.0.5 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.0.6 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.0.7 = INTEGER: 0 SNMPv2-SMI::enterprises.30054.1.0.8 = INTEGER: 66567 SNMPv2-SMI::enterprises.30054.1.0.9 = INTEGER: 7615 SNMPv2-SMI::enterprises.30054.1.0.10 = INTEGER: 5927 SNMPv2-SMI::enterprises.30054.1.0.11 = INTEGER: 22 SNMPv2-SMI::enterprises.30054.1.0.12 = INTEGER: 11028815 SNMPv2-SMI::enterprises.30054.1.0.13 = INTEGER: 33 SNMPv2-SMI::enterprises.30054.1.0.14 = INTEGER: 11089471 SNMPv2-SMI::enterprises.30054.1.0.15 = INTEGER: 7604 SNMPv2-SMI::enterprises.30054.1.0.16 = STRING: "Thu Dec 13 12:18:43 PST 2007" SNMPv2-SMI::enterprises.30054.1.0.17 = STRING: "Thu Dec 13 12:18:43 PST 2007" SNMPv2-SMI::enterprises.30054.1.0.18 = STRING: "Thu Dec 13 12:43:54 PST 2007" SNMPv2-SMI::enterprises.30054.1.0.19.1 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.2 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.3 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.4 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.5 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.6 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.7 = Counter32: 11 SNMPv2-SMI::enterprises.30054.1.0.19.8 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.9 = Counter32: 11 SNMPv2-SMI::enterprises.30054.1.0.19.10 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.11 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.12 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.13 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.14 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.15 = Counter32: 0 SNMPv2-SMI::enterprises.30054.1.0.19.16 = Counter32: 0
snmpd.conf
The snmpd.conf file required to allow UVM statistics to be queried by the SNMP agent is generated for you by the Untangle (Swing) Client. Open the Untangle Client, go to the Config/Remote Admin panel and select the Monitoring tab. Select the "Enable SNMP Monitoring" radio button and then fill in the necessary fields, ENSURING that the "Community" text field has the value untangle. Save these settings and the correct snmpd.conf file will be generated and the snmp daemon restarted. Here's an example of a valid snmpd.conf file as generated by the Untangle Client:
# Turn off SMUX - recommended way from the net-snmp folks # is to bind to a goofy IP smuxsocket 1.0.0.0 # Enable default SNMP traps to be sent trapsink MY_TRAP_HOST MY_TRAP_COMMUNITY 162 # Enable traps for failed auth (this is a security appliance) authtrapenable 1 # Physical system location syslocation HMB # System contact info syscontact HiltonKen sysservices 78 pass .1.3.6.1.4.1.30054.1 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh webfilter pass .1.3.6.1.4.1.30054.2 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh firewall pass .1.3.6.1.4.1.30054.3 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh attack pass .1.3.6.1.4.1.30054.4 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh protofilter pass .1.3.6.1.4.1.30054.5 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh ips pass .1.3.6.1.4.1.30054.6 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh phish pass .1.3.6.1.4.1.30054.7 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh router pass .1.3.6.1.4.1.30054.8 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh spyware pass .1.3.6.1.4.1.30054.9 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh virus pass .1.3.6.1.4.1.30054.10 /bin/sh /usr/share/untangle/bin/uvmsnmp.sh spam # Simple access rules, so there is only one read # only connumity. com2sec local default untangle group MyROGroup v1 local group MyROGroup v2c local group MyROGroup usm local view mib2 included .iso.org.dod.internet.mgmt.mib-2 view mib2 included .iso.org.dod.internet.private.1.30054 access MyROGroup "" any noauth exact mib2 none none
For Future Consideration
Currently, the "UVM" section of our MIB-tree, ie, .1.3.6.1.4.1.30054.0, is not populated with information. Here are some of the items that we may want to expose there:
- untangle-vm stats would be stuff that applies to the untangle-vm number of sessions, number of racks, settings, is user logged in? type stuff
- system stats would be stuff that applies to generic linux systems memory usage, disk usage, cpu load, NIC information, uptime
- Maximum/average number of sessions in timeframe <x>
- Peak/average throughput
- Count of connected computers (good for maintaining licensed revenue
stream)
- Configurable time-frame with reset capability
- Number of sessions
- Active User count
- Number of active connections
- Number of email processed passed in X number of seconds, minutes, hours
- Number of Spam blocked in X number of seconds, minutes, hours (same for web content, phish, virus)
- Network Speed (outbound)
- Network Speed (inside)
- Pages/Sec (again this is Windows world so )
- Number of threads
- Number of sockets open
- Process Count Active
- Process Count terminated
- Job Process ID
- Handle Count
- Memory Handling for Memory leak (there is a WHOLE fun world in Perfmon that I know how to set up to monitor CPU/Memory Usage/Memory leak that I have NO idea how to set up in Untangle)
- Total Transactions processed per second, minute, hour etc.
