How RMON works

Overview

RMON gives you one place to configure checks, choose where they run, review current and historical results, publish status pages, and send notifications.

You work with monitoring through the RMON web interface. RMON takes care of sending each check to the selected monitoring location and collecting the result.

Agents are installed and managed from RMON. You do not need to install or configure an agent separately.

From a check to an alert

1. Configure: create a check and define what a successful result looks like.
2. Choose a place: select an agent, country, region, or all available regions.
3. Run: the selected agent performs the check at the configured interval.
4. Collect: RMON receives the result and updates the dashboard and history.
5. Evaluate: retries, expected values, and thresholds determine whether the service is healthy.
6. Inform: RMON displays the state and sends alerts through the channels assigned to the check.

If the service recovers, the current state and its history are updated and the alert can be resolved in the selected notification channel.

Agents and locations

An agent represents a location from which checks are performed. For example, you can monitor the same website from an office, a data center, and an external region.

• Agent: one specific monitoring location.
• Country: the agents assigned to a country.
• Region: the agents grouped into a wider monitoring area.
• All regions: all currently available regional locations.

Running a check from several places helps distinguish a local connectivity problem from a service-wide incident. Give agents and locations clear names so users can immediately understand where a failed result came from.

For the user workflow, see Agents and Countries and regions.

Where results appear

• Dashboard: the current condition of monitored services and the locations reporting it.
• Check details: the latest result, response information, route data where available, and check settings.
• History: previous state changes and results for investigation and reporting.
• Notifications: incident and recovery messages delivered to the configured channels.
• Status pages: a shareable view containing only the checks you choose.

See Read check results, Notifications and alerting, and Status pages for the corresponding user guides.

Example: monitor a customer website

1. Create an HTTP check for the public website URL.
2. Select two or more monitoring locations that represent your users.
3. Set the expected status code and, if useful, a keyword that must appear on the page.
4. Set retries and a response-time threshold to reduce noise and highlight slow responses.
5. Assign an alert channel and add a runbook link for the team that will respond.
6. After checking the results, add the check to a customer-facing status page.

The same workflow applies to Ping, DNS, TCP, SMTP, and RabbitMQ checks: choose what to monitor, where to monitor it from, what counts as healthy, and who should be notified.