Server monitoring has never been easier

CloudRadar monitors hosts available through the public internet from different geographical locations. Agentless monitoring can be performed inside protected intranets behind a firewall too by installing the check-executer – called frontman – on-premise.

Checks are based on

• ICMP echo requests (ping)
• TCP Port checks
• HTTP Requests (HEAD, GET, POST)

A failed check is repeated two times on the original location and then forwarded to two neighbor locations and executed there three times. A check must be executed nine times to be considered as failed.

TCP Port checks provide options for

• Check if a TCP port is open
• Check if an open port answers with the expected protocol
• Specifying a custom timeout (coming soon)
• a check pre-flight prior to the regular execution to warn customers about configuration errors and checks which will immediately fail after adding (prevents misconfigurations).

HTTP checks provide options for

• ignoring SSL errors
• specifying a timeout
• searching for a pattern (control keyword) inside the HTML source code or inside the rendered HTML (no JS execution)
• specifying custom headers, for example, HTTP basic auth
• specifying an expected HTTP status code
• allow or disallow to follow redirects
• a check pre-flight to warn customers about check errors and checks which will immediately fail after adding, displaying HTTP status codes and other errors immediately (prevents misconfigurations)

To get the full insights into the operating system the installation of an agent is required.

The agent is available for

• Microsoft Windows (>= Windows 7), signed MSI package, supports unattended installations
• CentOS, Redhat, and derivates, RPM package, and yum-repository
• SuSE Linux, generic RPM packages are suitable, no repository provided.
• Debian- and Ubuntu Linux, DEB package, and Debian-repository, supporting x86, AMD64, and ARM architectures
• Mac OSX
• Plesk extension providing full integration into the Web-UI
• Synology package providing full integration into the Web-UI
• QNAP package, configuration, and installation through SSH
• Binary Packages (tar.gz) for any other Linux, supporting x86, AMD64, and ARM architectures

The agent monitors

• the utilization of the CPU (detailing iowait, user-, and system-load, idle), the sum of all CPUs and detailed metric of each CPU or core.
• the utilization of the memory with a detailed breakdown on cached, buffered, available and paged memory.
• the fill level of disks (mount points), discovered automatically, custom filters to in- or exclude disks and mount points can be set.
• the bandwidth usage of network cards, discovered automatically, custom filters for in- or excluding devices can be set.
• processes; the agent reports all processes and their states
• services which are automatically discovered through the Windows Service Manager or Linux SystemD. All discovered services and their states are reported.
• TCP and UDP ports opened by the OS
• processes causing a high load. So-called CPU utilization snapshots are taken. If the load hits a limit the most CPU consuming processes are recorded. The thresholds can be fine-tuned.
• hardware inventory, detailing the PCI cards, attached displays, mounted memory modules, attached USB devices, model and serial number of the mainboard, CPU model
• S.M.A.R.T disk health
• Temperatures reported by the sensors of the mainboard.
• For an easy configuration, the agent supports three presets for the most common use-cases
• heartbeat only, for customers just wanting to be alerted if a host is down
• minimalistic, for virtual machines, reporting just CPU, memory, and disk fill levels
• full, supporting all features mentioned above

For any data gathered by a script or third-party software, custom checks can be created.

• Via any HTTP client, e.g. curl, PowerShell, Python, measurement data can be submitted as JSON payload.
• An expected update interval can be assigned to custom checks to be warned if the sender stops sending.
• Graphs and a 30-day history are built automatically for any numeric values.
• A handy custom-check-sender binary is provided, useful for Windows users not having curl installed by default (coming soon).

• All measurements are displayed tabular and all numeric values are displayed also as graphs providing a 30-days history.
• Relevant metrics are grouped into pre-defined graphs for a quick overview of CPU- and memory utilization, disk fill levels, and bandwidth usage

For almost every measurement rules can be created. If a raw or processed value is below or above a threshold an event (alert or warning) is created. To avoid repetitive and error-prone creation of rules for each host, rules can be created for

• a single host identified by its UUID
• hosts identified by names supporting wildcards
• hosts identified by IP-address or FQDN supporting wildcards
• hosts having a specific tag

Conditions can be based on

• last, average, min, max of up to 10 measurements
• wildcard matches for processes and services

The rule creation is made comfortable and user-friendly by wizards which are launched from the measurement the rule should be based on. Depending on the context only applicable options are shown to avoid an overloaded UI.

Each account starts with a basic set of useful rules covering common use-cases.

For all or just specific hosts, status pages can be created. They are accessible without authentication under the neutral URL https://serverstate.info/

• A status page can be customized through a wizard supporting
• a custom header and footer with limited usage of HTML (WYSIWYG editor)
• a custom logo (image upload)
• number of days the history should cover
• which events to include (alerts and/or warnings)
• the hosts or hosts identified by tags the status page should cover

The status pages are available as

• full page, supporting auto refresh and dark theme
• HTML embed code, for usage inside an iframe, renders a small overview
• Image embed code renders a small overview (badge) as an image.

A public json-based REST-API is available for easy integration into third-party tools and scripts.

Through the Web-UI tokens for the bearer authentication is managed. An unlimited number of tokens can be created to fully control and revoke access.

Tokens can be limited to read operations.

The API does not support all features available through the Web-UI yet, but basic functions for managing hosts and fetching events are available. See all API features.

Events (alerts or warning) are sent to recipients via the following media

• Email
• Slack
• Telegram
• PushOver
• SMS
• Phone Calls (text to speech)
• WhatsApp
• Web Hooks

Besides events, a recipient can subscribe to

• reminders for unresolved issues with a custom reminder interval per recipient
• a short daily summary of the issues of the last 24 hours dispatched on midnight
• detailed daily, weekly or monthly reports
• comments on issues made by teammates

A recipient can filter which events to receive (message routing) based on

• The hostname(s) of the affected host, supporting wildcards
• Host tags, IP-address or FQDN of the affected host, supporting wildcards
• The event message, supporting wildcards
• all filter options can be combined by a logical AND or OR.For almost every measurement rules can be created. If a raw or processed value is below or above a threshold an event (alert or warning) is created. To avoid repetitive and error-prone creation of rules for each host, rules can be created for
• a single host identified by its UUID
• hosts identified by names supporting wildcards
• hosts identified by IP-address or FQDN supporting wildcards
• hosts having a specific tag

Conditions can be based on

• last, average, min, max of up to 10 measurements
• wildcard matches for processes and services

The rule creation is made comfortable and user-friendly by wizards which are launched from the measurement the rule should be based on. Depending on the context only applicable options are shown to avoid an overloaded UI.

Each account starts with a basic set of useful rules covering common use-cases.

The initial creator of the account can invite people to join the team. An invitation email is sent and the team is joined by clicking on the link. A password must be set.

Teammates can have one of the following roles

• Admin, with read-write access to everything
• Member, with read-write access to everything except the team management.
• Guest, read-only, not allowed to any configuration, limited to the dashboard and the measurements. A guest can be limited to host-group.

All activity of the teammates is recorded in an audit log allowing members to follow up who has made what when.