The MonBOX Remote Monitoring Appliance (MBR) is intended to make it easy to monitor systems and networks in remote or restricted access locations.

The MBR is a small, self-contained computer that can be installed where needed, and runs system and network checks locally, reporting the results back to a central monitoring server. The checks can be invoked by the MBR itself (through “tasks”) or can be invoked by the central monitoring server, via SSH or NRDP connections (if direct access to the device is available).

This means that you can monitor remote locations without requiring inbound access through your firewalls, and without needing to set up VPN connections.

An MBR can be completely managed through the centralized MonBOX Management Service (MMS), and requires no direct access to the device itself  — the device “calls home” (via HTTPS) periodically to check-in and receive instructions. If direct access (HTTPS) is available to the MBR, it can also be managed through a web management interface on the device itself. Basic configuration is also availble through the device console, or via SSH.

The MonBOX Management Service is a centralized service run “in the cloud” by SYONEX (the developer of the MBR). The MMS is accessed over HTTPS, through either the interactive web interface, or through a simple API. The API provides methods to manipulate an MBR, or to query or update the tasks to be performed by the MBR.

The MonBOX Remote Monitoring Appliance uses industry-standard Nagios plugins and protocols (NRDP, NRPE, NSCA) but can be used with almost any central monitoring server.

We hope that you find the MBR and MMS useful in your environment. But, we likely haven’t thought of every possible situation, and we may have overlooked some things. We would very much welcome any feedback or suggestions that you may have.

This section provides a few potential use case for the MBR and related tools, as a means of helping you become familiar with the possibilities.

The MBR is intended to be a tool that you can apply according to your needs and according to your environment.

The MonBOX Remote Monitoring Appliance provides a tool for working around limitations or restrictions in your network. Think of the MBR as another level of indirection that’s solving a problem in computer science.

Section <direct-checks-mbr> outlines some of the benefits of using the MBR, even when direct checks of services are possible.

	By default, the MonBOX Remote Monitoring Appliance is configured to automatically call out to the MMS, provide information about your network and the device to the MMS, and accept instructions from the MMS.

One of the primary features of the MonBOX Remote Monitoring Appliance is that it can be centrally managed and controlled, through the MonBOX Management Service. To make this possible:

The MBR and MMS are built and configured to only run commands on your network that you authorize, and to not run any commands or perform any activities that are not authorized by you, or that are likely to cause any disruption to your network or devices.

By default, the software installed on the MBR can be updated in response to a remote command, and the MBR can run commands allowed by the software. A software update could allow more commands to be run in response to remote commands.

This means that the MonBOX Management Service (i.e. the web-based service run and controlled by the developers of the MonBOX Remote Monitoring Appliance) has information about your network(s), and could (as a result of software updates and configuration changes) cause (essentially) arbitrary commands to run on the MBR, which is, of course, a computer attached to your network.

It is possible for you to change the configuration of the MBR so that it will not “call home”, interact with, or accept any commands from the MMS. This will disable the “remote control” abilities of the MBR/MMS system, but may be appropriate in some more restricted environments. Instructions on how to disable these features are in the subsection Disabling Remote Control and Reporting on the MBR, below.

We want you to understand what goes on “under the hood” so that you can decide whether or not the MBR/MMS combination is appropriate for your environment. Plesae contact us if you need additional information or details on how the MBR/MMS interactions work, to assist you in your evaluation of the MBR for your environment.

We think we’ve built a pretty useful tool for the system and network administrator’s toolbox. And we hope you think so too.

But, the MonBOX Remote Monitoring Appliance may not be a good match for every situation. In particular, we feel we should mention:

We recommend that you read the Limited Warranty, Disclaimer of Liability appendix.

We’ve tried to build a tool that will work in a variety of environments, and which will provide a good and useful service that will serve you well for a long time to come. But, unfortunately, a cost effective device like the MonBOX Remote Monitoring Appliance simply isn’t suitable for every need.

If you do have need of a remote monitoring tool for more challenging environments, please let us know, and we’ll see what we can do.

And you’re ready to go!

Next, you can use the MMS interface to change settings, and give it some tasks to do.

Each MBR comes with one year of support, access to any software updates that are released, and one year of access to the MonBOX Management Service.

If you run into any problems, or have any questions or suggestions for the MBR and/or its related services, please drop us a line and we will do our best to help you out.

Each MBR has a unique name — the name is on the label on the MBR, and is shown in the MBR’s administrative menu, web management interface, and in the MMS.

When initially connected to a network, an MBR will attampt to use DHCP to acquire an IP address. If desired (or required) a static address can be configured through the MBR’s web management interface or administrative menu. The current IP address is visible in the MBR’s web management interface and administrative menu.

When an MBR calls home to the MMS, the MMS will set up a dynamic DNS entry for the MBR (which will typically be available on the public network within 15 minutes). The dynamic DNS names are in the mbr.monbox.com domain, so an MBR named “bob” will show up in DNS as bob.mbr.monbox.com. (This DNS name is also included on the label on the MBR.)

Please note that in most cases, the IP address will be an “internal” network address (behind a firewall) so will typically be of limited use from other outside networks.

There are several security mechanisms used by the MonBOX Remote Monitoring Appliance

8.4. Disabling Remote Control and Reporting on the MBR

	We really recommend that you do not disable the remote control features of the MBR, because we think that you’ll be limiting the utility of the device, and missing out on some great features. But we would be remiss if we didn’t make it possible for you to decide for yourself what’s most appropriate for your environment.

By default, the MonBOX Remote Monitoring Appliance calls the MonBOX Management Service periodically, and accepts commands, configuration, and other information from the MMS. We think this is one of the great features of the MBR, and hope you do too.

However, if you wish to disable these features, this is how to do it. Access to the MBR web management interface is required to disable or re-enable these features.

• Tasks, such as update, reboot, cron and Nagios object configuration. To stop the MBR from accepting task requests from the MMS, choose Config / Tasks from the web management interface menu, and on the “Tasks Configuration” page, set “Enable Tasks” to “No”, and save the configuration.
• CallHome, the periodic reporting of current operational state to the MMS. To stop the MBR from “calling home” to report on its state and well-being, choose System / Config / CallHome from the web management interface menu and on the “CallHome Configuration” page, set “Enable CallHome” to “No”, and save the configuration.

Again, we hope that you will choose to keep these features enabled. If you have concerns or questions about the operation of these features, please feel free to contact us and we will do our best to help you out.

The MonBOX Remote Monitoring Appliance is built on the Raspberry Pi single board computer.

We chose to use the Raspberry Pi because of its combination of no moving parts, high function and low cost, and its compact size.

The underlying OS is Raspbian, a Debian derivative optimized for the Raspberry Pi, with a variety of open source software packages on top.

We have stripped down the base OS installation, written all sorts of tools to implement the MBR functionality, and wrapped it all up with tools to run with a read only filesystem.

We use a read only filesystem for added system reliability. It greatly reduces the possibility of a corrupted filesystem (in cases of system or power failure), and reduces the number of writes to the SD card (which is reputed to make the card last longer). Plus, writing SD card on a Raspberry Pi is not blindingly fast, so if we avoid SD card writes, and use a memory filesystem instead, we should have better overall performance.

But because it’s a read only filesystem, things aren’t quite as they would be on a “normal” computer. So we ask you to resist the urge to use the shell access that is available on your MBR to attempt to make your own modifications.

The MBR is intended to be easy (dare we say trivial?) to install and to require little or no maintenance.

Installation is typically just as simple as described in the Quick Start section.

As is common, there are no user serviceable parts (or software) inside. The administrative menu provides a shell access menu item, primarily as a tool for trouble shooting.

No ongoing hardware maintenance is required. You should check for software updates periodically, and apply any recommended updates, either through the administrative menu, or through the MMS.

The MonBOX Remote Monitoring Appliance is intended to be a reliable and effective tool for system and network monitoring in remote or less accessible environments.

The web management interface and administrative menu on the MBR, coupled with the MonBOX Management Service, are intended to eliminate the need (or perceived need) to customize the operating system and environment on the MBR. And, combined with the read only filesystem, and other tools and mechanisms on the MBR, the intention is to make it difficult to manually (or otherwise) modify the MBR. This is intended to improve the overall reliability and security of the device.

Because we expect that many or most MBRs will be installed in remote locations, or at customer premises, we recognize that a software, system, or configuration error that renders an MBR inaccessible or ineffective could be very inconvenient to fix. Avoiding these kinds of problems is the primary reason for using a read only filesystem, and for limiting uncontrolled administrative access to the MBR.

Functionally, the MBR performs a small number of activities:

The MonBOX Management Service (MMS) provides a centralized management interface for control of and reporting on your MBR devices. The MMS is a centralized service provided by SYONEX for use in managing MBR devices.

The MMS is used for management, and is not required for ongoing monitoring. If the MMS is unavailable or unreacahble for a short period of time, your monitoring processes will (in most cases) be unaffected.

Each MBR is recorded in MMS, and is associated with an account, and each account (for a company or organization) has one or more userids associated with it. Userids are in the form of email addresses, and each userid associated with an account can control the account and the devices associated with the account.

The primary menu items in the MMS are Home, Devices, Account, Password, Help and Logout. The Account submenu provides information on the account (name, address, etc.), management of the users associated with the account, and account API access control and token generation.

Some of the pages in the MMS have a ContextHelp menu item, which links to the appropriate section in the MonBOX Remote Monitoring Appliance User Guide.

The MonBOX Relay Service provides a method for a device running monitoring checks to transfer the results back to a monitoring server, without requiring a direct connection between the systems (in either direction). The check results are passed from the MBR to your monitoring server through the MRS intermediary, which means that “inbound” network connections to the MBR or the monitoring server are not required. i.e. You don’t need to open your firewall on either end in order to monitor your networks.

The MRS is a centralized service provided by SYONEX for use in managing MBR devices. If you are using the MRS as part of your monitoring, and the MRS is temporarily unavailable or unreacahble, your monitoring results will be unavailable during that time. The MBR is built with reliability in mind — we want to avoid service disruptions even more than you do. If you have concerns about MBR reliability or availability, please contact us, and we will try to answer your questions, and offer suggestions about how to configure your monitoring environment and checks to help ensure that your needs are met.

The checking device runs a service check (e.g. checks that an HTTP server is serving up pages), reports the results of the check to the MRS, and the monitoring server periodically polls the MRS for the most recent check result. Communication is via NRDP.

The MRS was inspired by the Nagios Reflector service.

Authentication for the MRS is by way of a relay token, using a distinct token for each MBR. When a relay token is (re-)generated, the MMS creates a task to transfer the new token to the MBR. This means that MRS authentication for use from an MBR is automatic. You will, however, have to copy the relay token to your monitoring server.

To collect check results from the MRS, use the check_reflector.py plugin (which is available at http://assets.nagios.com/downloads/exchange/reflector/check_reflector.py) on your monitoring server to poll the MRS.

On the MBR, use the fragments mechanism provided through the MMS (see “Tasks and Fragments” below) to run checks and report the results to MRS.

You can, of course, submit an MBR’s check results to any NRDP or NSCA server, using the nrdp_check and nsca_check tools. We’ve tried to provide “mechanism not policy”, so that the MBR can be used in the way that works best for your environment and your network.

The MBR itself allows local management of its settings and configuration. And, if your MBR is directly accessible on your network from your central monitoring server, there are several ways that your server can connect to the MBR and cause monitoring checks to run.

If you’re not sure where your MBR is on your network, see the section Finding an MBR on the Network, above. And you may wish to review the subsection on MBR Access for security and access control information.

If the MBR is reachable on your network from your central monitoring server, you can send direct monitoring checks through the MBR by two methods: SSH and NRPE.

If the MBR is accessible on your network, isn’t it possible that the other devices on the same subnet are also accessible? And if so, what are the advantages of checking via the MBR rather than checking the devices directly?

Monitoring checks can be run on (or through) the MBR using the standard check_by_ssh and check_nrpe plugins.

For ease of integration into an existing monitoring system, you may find the MBdivert plugin wrapper useful. MBdivert was written to make “diverting” checks through an MBR easy. The mbdivert.cfg configuration file provides rules to transparently divert checks through an MBR (or any other system running SSH or NRPE). More information on MBdivert (and the MBdivert software distribution itself) is available at http://www.syonex.com/resources/software/

The MMS provides the ability to create and manage configuration “fragments” that are transferred to the MBR and used to run monitoring checks and (presumably) report the results to a central monitoring server. Fragments can be modified both through the MMS web interface and through the MMS API.

There are two types of fragments:

Fragment files are processed in alphabetical order, and multiple files are effectively equivalent to a single file containing the same content. The ability to have multiple fragment files is intended to make your life easier, and allow you to organize your settings in the way that works best for you. For example, you could use a separate fragment file for each host that you are monitoring.

From the point of view of a central monitoring server, checks run via Cron or NagiosObjects fragments are likely “passive” checks (using the Nagios terminology). That is, these are checks that are not directly invoked by the central monitoring server, but instead are invoked by another system and the results of checks are reported back to the central monitoring server. (Use of the MonBOX Relay Service blurs this distinction somewhat.)

nsca_check -q -h nsca.example.com \
    -S www -H google check_http -H google.com

nrdp_check -q -t token -u https://www.example.com/nrdp/ \
    -S www -H google check_http -H google.com

relay_check -q -S www -H google check_http -H google.com

# This is a comment

# We want the checks to run every 3 minutes
interval 3

# Define an NSCA server named "mynsca" on the host nsca.example.com
# using the defined port
server mynsca nsca nsca.example.com

# Define an NRDP server named "mynrdp" on the host nrdp.example.com
# using HTTPS, and mytoken for authentication.
server mynrdp nrdp mytoken https://nrdp.example.com/nrdp/

# Check HTTP to google.com, and report it to the mynrdp server (the
# most recently referred to server), and label the result with host
# "google" and service "www"
check www:google check_http -H google.com
# Check google.ca and report and tag the service "wwwca"
check wwwca check_http -H google.ca

# Check HTTP to monbox.com, and report the result to the NSCA server
# "mynsca", tagged as host "monbox" and service "www"
check www:monbox:mynsca check_http -H monbox.com
# Check HTTPS to monbox.com, and report to the same server.
check secure check_http -S -H secure.monbox.com

# We want the following checks to be run every 5 minutes
interval 5

# Check SMTP to smtp.syonex.com and use the MRS to report it
relay smtp:syonex check_smtp -H smtp.syonex.com
# Check HTTP to www.syonex.com
relay smtp check_http -H www.syonex.com

# This is intended to be the minumum set of objects that do nothing
# that will stop any pre-flight errors and warnings.

define contact{
    contact_name                        nocontact
    alias                               nocontact
    service_notification_period         never
    host_notification_period            never
    service_notification_commands       nocommand
    host_notification_commands          nocommand
}
define contactgroup{
    contactgroup_name                   nocontactgroup
}
define timeperiod{
    timeperiod_name                     never
    alias                               never
}
define command {
    command_name                        nocommand
    command_line                        /bin/true
}
define host {
    host_name                           nohost
    alias                               nohost
    hostgroups                          nohostgroup
    check_command                       nocommand
    max_check_attempts                  1
    contact_groups                      nocontactgroup
    notification_period                 never
    check_period                        never

}
define hostgroup {
    hostgroup_name                      nohostgroup
    alias                               nohostgroup
}
define service {
    service_description                 noservice
    host_name                           nohost
    check_command                       nocommand
    max_check_attempts                  1
    notification_period                 never
    check_period                        never
}

There is a simple API for accessing the MonBOX Management Service. The API is intended to make it possible to integrate your MBR into your existing systems without too much trouble.

The API is built on HTTPS, using a simple token based authentication mechanism, combined with your Account Code used in the API URL. There is one API access token per account, which is (re-)generated through the MMS. When authenticating, use the API token as the username, and use an arbitrary filler string for the password (only the token is used for authentication).

Here is a simple example, which gets a list of devices in your account (assuming your Account Code is abcdco and your token is 123456):

% curl -u 123456:x https://secure.monbox.com/api/v1/abcdco/devlist
liststart
listlegend device name tasks updates lastintip lastextip lastcontact
device apple Yes No 192.168.1.111 1.2.3.4 1363229589
device banana Yes No 192.168.1.222 1.2.3.4 1363229761
listend
apiend

A few notes: