Don't have an account? Register now!

Xenguard Server software

The Xenguard web interface provides centralized tracking of critical metrics on every sensor node on your network. With an intuitive GUI, superior analytics, mobile device support and a powerful integration API, Xenguard provides network security administrators with a single tool, capable of protecting large-scale and complex architectures. Network security personnel around the world benefit from the power of Xenguard in a way that far exceeds any other network security solution. The Xenguard web interface provides a centralized point to facilitate rapid diagnostics and data retention, automatically respond to conditions such as hard disc failures, stack overflows, etc. Alerts of critical conditions are generated -- nodes down, services not running, overheating, disc failures etc. The data is easy to understand and presented in graphical form. This eliminates guesswork and speeds resolution of problems because the situation is proven, allowing management to take decisive action such as resource provisioning or disabling misbehaving software components. The Xenguard system features an advanced target data processing engine, which maintains a comprehensive history of your network traffic for real-time or on-demand analysis.


A person record contains a list of devices that they own or use (MAC). A person may be associated with an organization.



A MAC address is the physical identifier of a hardware interface. It is associated with one or more ARPs (IP addresses that are used by the device). Each MAC has a list of other MAC addresses that it has communicated with. ARPs are locally-detected MAC-to-IP-address mappings. Note that we often cannot obtain an ARP for a remote IP address on somebody elses network - that is, we dont know the MAC address of the remote IP address (this would generally require a Xenguard system listening at both ends). When an ARP is detected, this verifies that a particular MAC address is associated with a particular IP address. Each IP4 address has a list of peers that it communicates with. We capture time-stamps of the times a particular IP address is used on a particular subnet. We also gather details about the registered owner of the IP address, and the Autonomous System Number (ASN) it is associated with. The Xenguard system captures each of the protocols utilized by a particular IP address (most commonly, TCP, UDP and ICMP). The Xenguard system captures details on the owner organization for internet ASNs.


Events are incidents where a non-normal reading has been detected from any of the system's sensors. Events may be imported to the Xenguard Server directly (for example, via syslog), or the Xenguard Server will generate events internally when any sensor registers a non-normal value. Several filtering options are used to select events. The event class can be problem (a sensor has returned a non-normal value), or recovery (a sensor has returned to normal value). Each event is associated with one or more nodes these are the monitoring hosts to which the sensors are connected. Events may be selected via the sensor class for example syslog, video, or SNMP. The system log (syslog) facility contains a wealth of valuable information on almost any device type. Automated syslog event monitoring is an amazingly effective technique! It can detect disc errors, crashing applications, memory exhaustion, firewall violations and almost anything worth knowing about a device.


Sensors are data sources which are monitored by the Xenguard system. A sensor can be anything from an SNMP OID to a video camera. Each sensor is associated with a node, which is the host that the sensor is connected to. Some sensors are real-time (such as syslog or camera classes), and others are polled (such as web or file classes). A sensor's group indicates which group of contacts owns a sensor who is authorized to access sensor information and/or manage their configuration. Individual sensors may have related alerts enabled or disabled (for example, when performing maintenance on a device). The sensors dialog displays a summary list of configured sensors. Sensors in a problematic state are highlighted in red. Use the node class and node selector to filter the sensor list by it's node and node class (server, portable computer). Use the sensor class selector to filter the sensor list by class (SNMP, video etc.) Click the edit button to make changes to a sensor. Click the name of the sensor to access detailed monitoring statistics. A sensor type indicates the sort of data we expect the sensor to give us. For example many devices/sensors provide thermal sensors, and many also have RAM. A class of sensors can have one or more sensor types applicable to it for example memory is applicable to routers, switches, servers and so on. A sensor is monitored via polls and/or real-time event handling (traps). If a proxy node is defined, the Xenguard system will conduct probes via this proxy. For example, devices on a non-routable private network cannot be directly monitored from the internet without an intermediary host (proxy). The notes field contains miscellaneous notes about the device. For user convenience, a number of standard sensor templates are provided for most common types of sensors.

CPU load

High CPU load (over load 1 in most cases) is often a sign of serious problems with a device and/or bad resource management. While there are cases where a server will be at 100% utilization continuously for a considerable duration (cryptography, video rendering), these cases are rare for general-purpose servers. While > 1 load does not necessarily mean things are going to blow up, it does mean that functionality to the users accessing these services is degraded (a load of 5.0 generally means that processes run at 20% of their normal speed). We recommend warning on a per-core load over 1.0, and alerting on a per-core load over 5.0. Memory exhaustion is of course a frequent cause of server failures. Memory utilization on Linux is actually a bit tricky to monitor, because of the way it rapidly utilizes memory for I/O caches (improving performance) but the kernel does give us a sure-fire indicator of issues swap utilization. There are very complex ways to control memory utilization and swappiness but in simple terms, the kernel won't swap until it really needs to (memory needed by user processes, not I/O caches). So we can simply watch for swap utilization and trigger at > 1% utilization. It's normal for the swap to be a little bit allocated but > 1% means that service is degrading and something is wrong.


Xenguard management system
contact Xenguard
Xenguard services
Xenguard software
Xenguard news
Xenguard library
Copyright © 2013-2020 by Xenguard. All rights reserved.