Section 1 – Overview
Mutiny is a self-contained monitoring platform (available as an appliance, virtual machine, or hosted deployment) for network-attached devices such as servers, switches, routers, printers, and other manageable systems. It is designed to be simple to use, aimed at people who want clear operational information — without needing to become experts in the underlying collection technologies.
The purpose of Mutiny is to monitor systems that are critical to the operation of your network services, and to send alerts (email and SMS) to operators when problems are detected.
Mutiny gathers data from devices using a range of standard TCP/IP-based protocols. The two most important are ICMP (“ping”) and SNMP (Simple Network Management Protocol). For the best experience, devices should permit Mutiny read-only SNMP access. Unlike many SNMP-based monitoring tools, Mutiny does not require users to understand SNMP in depth. In practice, there are only four key requirements:
1. Know that SNMP exists.
2. Know how to enable SNMP read access on critical devices (such as Windows servers, switches, and routers).
3. Know how to configure SNMP security using the “community” (or “community string”) and restrict access to authorised monitoring systems.
4. Appreciate that where devices are monitored across a firewall, the firewall must permit SNMP access to those devices.
That’s it — because once Mutiny is instructed to monitor a specific device that supports SNMP (or one of our other polling technologies), it will automatically configure what it needs, begin monitoring, and start collecting data immediately.
Mutiny’s front-end is entirely web-based, so it is accessed through a web browser. To connect to Mutiny, enter its IP address or DNS name into your browser’s address bar and press Enter. You will then see the Mutiny Login Page. Sign in, and the Main Monitoring View will be displayed.
There are five user access levels in Mutiny:
Super Admin – Full access to monitoring and system configuration.
Admin – Full access to monitoring configuration.
Engineer – View-only access, with permission to edit node properties.
View – View-only access with no ability to make changes.
Embedded / Published – Allows a single view to be published or embedded into an intranet (for example SharePoint) for display purposes.
With the exception of Embedded / Published, all access levels require a username and password.
1.1 The Main Monitoring Views
In Mutiny you can define multiple “Views” of your estate, each containing the devices relevant to a specific service, location, or operational grouping. Each view can be displayed in several formats:
- Icon view
- Cards view
- Grid view
- Table view
- Graph view
- Top Tens
- Topology View
- Map view
- Wallboard
A number of views are pre-defined. After logging in, you will typically see the All Nodes view. As its name implies, All Nodes displays every device (node) currently being monitored. Nodes are shown as icons representing either single devices:
…or groups of devices:
Each icon includes a name beneath it identifying the device (or group). Icons also display a Status Indicator symbol showing the overall status.
The full set of Mutiny statuses and their meanings are as follows:
 |
|
The status symbol on a single-device icon reflects the worst state of all monitored properties on that device. For example, if an icon shows Warning, then at least one monitored property is in a Warning state, and none are in Critical (otherwise the icon would show Critical).
The status symbol on a group icon reflects the worst state of any device within the group. If a group icon shows Critical, then at least one device in that group is Critical.
1.2 The Mutiny Polling Cycle
Mutiny contacts each monitored device once every minute (and may probe multiple times per minute for ICMP). This is known as the polling cycle. Although it is possible to increase the interval so devices are polled less frequently, this is not generally recommended because Mutiny’s alerting behaviour is optimised around a one-minute cycle.
Polling involves checking connectivity and collecting the status of monitored properties. Because most data is obtained via SNMP, Mutiny typically starts by confirming that the device is reachable (using ping) and that it is responding to SNMP requests.
If Mutiny does not receive SNMP responses from a device, it will automatically revert to monitoring that device using ping-only. Likewise, if a device fails to respond to ping during a polling cycle, Mutiny will back off SNMP monitoring for subsequent cycles until ping connectivity is restored. This approach reduces unnecessary traffic during connectivity problems.
1.3 Drilling Down for Detailed Status Information
The Mutiny interface allows you to “drill down” into a device or group to investigate the status of individual properties.
Hovering over a device icon showing Warning or Critical will display a small message box listing properties currently in those states.
To drill down, move the mouse over a device or group icon and double-click.
Double-clicking a group icon switches to the view represented by that group icon and displays all devices in the view.
Clicking a device icon opens the main Status Panel for that device (node).
1.4 The Main Status Panel
The Status Panel lists the sets of properties currently monitored on the node. The list varies depending on device type and operating system, but a typical set for a Microsoft Windows server is shown below:
Each property set (for example Disk) is shown as a hyperlink. Selecting it opens a more detailed status panel for that property set.
The Status Panel also includes summary information such as the configured node name, polled IP address, DNS name (if a PTR record exists), and operating system.
Working from top to bottom, the main property sets and their associated panels are described below.
1.5 Ping Status Panel
The Ping property set shows the results obtained by pinging one or more IP addresses associated with interfaces on the device. Each result is either:
OK – A ping reply was received.
Critical – No ping reply was received.
Where ping replies are received, the Round Trip Time (RTT) is shown in milliseconds.
Tick boxes next to each interface determine which IP addresses Mutiny polls. These can be selected or de-selected as required.
The overall Ping status is determined by the worst case across all selected IP addresses. If Mutiny is configured to ping multiple IP addresses and some respond while others do not, the overall Ping status is set to Warning. If none respond, the overall Ping status is set to Critical. Ping status can also be set to Ignored if Node Polling is configured to Ignore Connectivity (see later).
Because data shown in a status panel may be up to one minute old (or longer if the polling interval is increased), each status panel includes a Test button.
Selecting Test instructs Mutiny to immediately perform the appropriate checks (in this case pinging all known IP addresses) and display the results.
If Data Collection is enabled for the node (described later), the IP address is shown as a link. Selecting it opens a quick graph of RTT with selectable time periods.
Also shown are three buttons marked OK, Warning and Critical, used to configure whether and how alerts are sent when a Ping event is detected. This is covered later in the Events and Alerts section.
1.6 SNMP Status Panel
Mutiny confirms that the device’s SNMP agent is responding by requesting its uptime. Uptime is usually the time since the device last restarted, although on some systems (such as servers) the SNMP service can be restarted independently. In most cases, the uptime value itself is not important — the key requirement is that the device responds reliably to SNMP queries.
Although it is possible for an SNMP agent to fail while the rest of the device continues operating, an SNMP failure often indicates the device is under resource pressure and may require investigation.
Obtaining SNMP responses requires that Mutiny is configured with the correct community string and that the device’s SNMP security settings allow responses to Mutiny (see the How SNMP Works section later).
As with other panels, a Test button is provided to retrieve the current SNMP status and additional detail. There are also buttons used to configure alerting for SNMP OK and Critical events.
1.7 Interfaces, Status and Thresholds Panels
The Interfaces panel shows the status of monitored network interfaces on the device. Mutiny uses SNMP to track:
• Interface state (Up/Down)
• Current traffic (Bytes/s)
• Usage as a percentage of available bandwidth (based on interface speed)
• Error rate (errors/s)
Tick boxes next to each interface determine whether that interface is monitored.
When a device is added to Mutiny, interface properties are read via SNMP and displayed as a table with one row per interface, including:
• Interface index
• Interface description
• Status Indicator (OK, Warning, Critical, Not Polled, or Ignored)
• State (Up, Down, Unknown)
• Input rate (Bytes/s) and usage (%) and error rate (errors/s)
• Output rate (Bytes/s) and usage (%) and error rate (errors/s)
• Per-interface polling selection tick box
Interfaces that are Up at the time of discovery are automatically enabled for polling. A tick box at the bottom of the panel enables or disables polling of all interfaces in one action.
As with other panels, a Test button displays the current state of interfaces. There are also two sets of alert configuration buttons (OK/Warning/Critical) used to configure alerting for interface Status and interface Usage events.
At the bottom of the panel is a button to open the Interfaces Thresholds panel:
The Thresholds panel provides per-interface warning and critical thresholds for usage, and options to ignore interface-down conditions. The interface status is calculated as follows:
• Critical if the interface is polled, state is Down, and Ignore Connectivity is not enabled.
• Critical if the interface is polled, state is Up, and input or output usage is greater than or equal to the configured Critical threshold.
• Warning if the interface is polled and input or output error rate is greater than or equal to 60 errors per minute.
• Warning if the interface is polled, state is Up, and input or output usage is greater than or equal to the configured Warning threshold.
1.8 CPU Usage Panel
The CPU Usage panel contains Warning and Critical thresholds. Because Mutiny can monitor both Windows and UNIX-like operating systems, CPU is presented differently:
• Windows – CPU is shown as a decimal percentage (for example 0.85 means 85% utilisation).
• UNIX/Linux – CPU is represented as load average, which may be any positive number reflecting process demand relative to CPU capacity.
Exceeding thresholds triggers Warning or Critical events.
The Show button displays current utilisation (multi-core systems show individual CPU values). If Data Collection is enabled and historical data exists, the utilisation value is shown as a link. Selecting it opens the quick graph panel (by default showing the last week).
Select a time period from the drop-down list to redraw the graph.
1.9 Memory Usage Panel
The Memory panel allows you to set percentage thresholds for memory usage. Exceeding thresholds triggers Warning or Critical events. If Data Collection is enabled and historical data exists, the utilisation value is shown as a link and opens the quick graph panel (by default showing the last week).
1.10 Disk Usage Panel
During discovery, Mutiny identifies fixed disks and automatically adds them to the Disk panel. Mutiny uses a table of disk sizes to apply sensible default Warning and Critical thresholds. These thresholds can be edited to suit your environment. Exceeding thresholds triggers disk events.
Selecting Show displays all attached storage, including removable devices.
1.11 Processes Panel
During discovery, Mutiny checks for key processes from an internal list and adds any that are found running to the monitored Processes list.
Name
The name of the process or service.
Status
The status indicator depicts the current state of the process.
Process Count
The number of instances currently running.
Should Run
Controls whether the process is expected to be running.
If ticked, the Minimum and Maximum fields can be used to define acceptable bounds. A Critical status is set if the count is below Minimum. A Warning status is set if the count is above Maximum. The default is Minimum 1 and no Maximum.
If not ticked, Mutiny expects the process not to be running. A Critical status is set if any instances are detected.
Minimum
Minimum number of instances that should be running.
Maximum
Maximum number of instances that should be running.
1.12 Agents Panel
The Agents panel provides details on the state of node-level checks monitored through Mutiny agents, and allows their activation or deactivation.
Agents may run locally on the Mutiny system or be installed remotely on the node. Agents are typically used to collect additional data such as temperatures, UPS status, RAID health, power supplies, and other manufacturer-provided health metrics.
Note: If an agent is a Remote Agent, it may also be monitored separately as a process.
1.13 IP Services Panel
The IP Services panel provides service tests at the TCP level (or higher) to determine whether an application or service is functioning.
Service tests include:
HTTP – Checks for content on a page.
IMAP – Tests an IMAP mailbox.
POP3 – Tests a POP3 mailbox.
MySQL – Tests a MySQL instance.
Open Port – Checks whether a TCP port can be opened.
SMTP – Configures polling parameters for an SMTP service.
DNS – Configures polling parameters for a DNS service.
Each test supports Warning and Critical thresholds and provides graphed response time.
The example graph above shows the response time of the Mutiny web server over a one-week period.
1.14 Status Panel Buttons
1.14.1 Configure
The Configure panel establishes node identification and polling behaviour. It also allows selection of the node icon type and remote connection method.
Node Name
Sets the name displayed in Mutiny.
IP Address
Sets the node’s primary IP address used for polling.
DNS Name
Displays the name retrieved from the configured DNS server (assuming a DNS server is set under System Configuration in the Admin section).
sysName
The node’s system name as read via SNMP.
Set Name As
Up to three buttons may be shown (where data is available) to set the Node Name to the IP address, SNMP sysName, or DNS name.
Icon Type
Selects the icon used to depict the node in Mutiny views.
Connect Method
Selects the URL template used for remote connection.
Node Polling
Sets the polling type for the node:
On – Node will be polled.
Ignore Connectivity – Node will be polled, but ping failure will not affect the overall node status.
Off – Node will not be polled.
Node Alerts
Enables or disables alert delivery for events raised by this node:
On – Alerts will be sent as defined by Event/Alert settings per contact.
Off – Alerts will be generated and queued, but not sent.
Poll Interval (mins)
Sets the minimum polling interval (minutes). The recommended value is 1.
Ping Polling
Controls whether the node is pinged at the start of each polling cycle (recommended: On).
SNMP Polling
Controls whether basic SNMP checks are performed:
Always – Always poll with SNMP.
Only if Ping OK – Poll with SNMP only when ping is OK.
Off – Do not poll with SNMP.
SNMP Agent
Configures parameters used to poll the node’s SNMP agent.
Port Number
UDP port for SNMP (normally 161).
Community String
Read-only community string used for SNMP access.
Retries
Maximum number of SNMP retries before the SNMP agent is considered down.
System Polling
Controls whether host resources (system) SNMP polling is performed:
Always – Always poll system resources.
Only if Ping OK – Poll only when ping is OK.
Only if SNMP OK – Poll only when SNMP is OK.
Off – Do not poll system resources.
System Agent
Configures parameters used to poll host resources.
Same as SNMP
When enabled, mirrors the SNMP Agent settings (recommended).
Port Number
UDP port for SNMP (normally 161).
Community String
Read-only community string used for SNMP access.
Retries
Maximum number of SNMP retries before the System Agent is considered down.
1.14.2 Configure Panel Sub-Buttons
Update SNMP Info
Refreshes SNMP-based node information and updates the node properties.
Reset Polling
Resets polling configuration to default values. This is similar to deleting and re-adding the node, but historical data is preserved.
Adapters
Opens the panel used to configure SNMP Polling Adapters for the node.
Save SNMP Walk
Captures an SNMP walk from the node. The walk file can be emailed to Mutiny Support to assess feasibility for additional SNMP adapters.
1.14.3 Properties
Opens the node’s properties (used for graphing and analysis). Values are populated during discovery and can be refreshed using Reset Polling.
1.14.4 SNMP Info
Executes a range of SNMP queries to obtain detailed system information.
1.14.5 Collect Data
Opens the panel used to configure node data collection settings.
Collect System Data – Stores CPU, Memory and Disk history for graphing.
Collect Traffic Data – Stores interface traffic history.
1.14.6 Connect
Initiates a remote connection to the node.
Telnet is commonly used for terminal access to UNIX/Linux systems, and VNC for Windows systems (where appropriate). The available connection methods are defined in Connect Strings under Administration.
Please note: remote connection methods are limited to protocols and applications that can be launched from a URL (because Mutiny is running in a browser).
1.14.7 Graphing
Only visible if Data Collection is enabled. Opens the node’s graphing and data analysis section.
Depending on available data, one or more buttons will appear on the left-hand side (for example Traffic, ISDN, QoS Data, System Data). For each group, use the drop-down menus to select the data series, units, and time period. Select Graph Data to generate the output.
The graph image can be copied or saved by right-clicking on the image. To export data in CSV format, select Save Data.
1.15 Static Alerts
Where a status panel includes a Static Alerts button you can configure the alert behaviour when an event is triggered. This methond should only be used if the Tracked Views alerting method (Section 9.) does not give you enough granularity.
The example above shows a contact enabled for email alerts across all three shifts with a 10-minute delay, but not enabled for Page/SMS. The additional action at the bottom can be used with or without a contact.
Available action types include:
• Send v1 Trap
• Send v2c Inform
• Custom
The list of custom actions depends on bespoke agents developed by Mutiny to end-user specifications.
For detailed operation of alerting in Mutiny, see the section on Alerting.
You may also wish to consider the Tracked Views method for a simpler, system-wide alerting policy:
https://mutiny.freshdesk.com/support/solutions/articles/13000087793-tracked-views
