Field and Check Types Reference

The Check type and fields reference provides details about the following agent check types supported by the Rackspace Monitoring service.

• Remote check types
• Agent check types
• Hostinfo checks
• Check status codes

Note

Most check types include some example metrics. This helps you better understand creating successful alarm criteria.

Remote check types

Rackspace Monitoring supports the following remote check types.

• remote.dns
• remote.ftp-banner
• remote.http
• remote.imap-banner
• remote.mssql-banner
• remote.mysql-banner
• remote.ping
• remote.pop3-banner
• remote.postgresql-banner
• remote.smtp-banner
• remote.smtp
• remote.ssh
• remote.tcp
• remote.telnet-banner

remote.dns

The remote.dns check run a DNS check against a given target. This check should assist in verifying functionality of a DNS server, for example ensuring that it is publishing the domains you think that it should be publishing.

Attributes

Metrics

remote.ftp-banner

The remote.ftp-banner check will attempt to connect to a FTP server and verify that it re- sponds to the connection.

Attributes

Metrics

remote.http

The remote.http check will try to connect to the server and retrieve the specified URL using the specified method, optionally with the password and user for authentication, using SSL, and checking the body with a regex. This can be used to test that a web application running on a server is responding without generating error messages. It can also test if the SSL certificate is valid.

Note: The maximum size of the content returned in a remote.http check is 500k, with overhead and compression taken into account. This limitation helps monitoring remain responsive.

Attributes

Note

When you set up a website and the check always returns unknown content-encoding: it is because of the HTTP body check limit of 100. This limit is the amount of space for the Monitoring Pollers (where the site is checked from). If the amount of space required to do the HTTP(S) check is greater than 100k, then only the first 100k can be checked.

If the customer uses Compression on the pages, such as compress or gzip Content-Encoding, then the full compressed page must be less than or equal to 100k. This is because the full page must be downloaded and uncompressed before it can verify the check.

This is also the reason why you can only check against strings within the first 100k of the web page.

Metrics

Note

The following is an example alarm for cert_subject_alternative_names, where you would replace example.com with an expected host name on the certificate’s SAN list:

if (metric['cert_subject_alternative_names'] nregex '.*example.com.*') {
return new AlarmStatus(CRITICAL, 'Missing expected SAN');
}

remote.imap-banner

The remote.imap-banner check will attempt to connect to an IMAP server and verify that it response to the connection

Attributes

remote.mssql-banner

The remote.mssql-banner check will attempt to connect to a Microsoft SQL database server and verify that it is accepting connections.

Attributes

remote.mysql-banner

The remote.mysql-banner check will attempt to connect to a MySQL database server and verify that it is accepting connections.

Attributes

remote.ping

The remote.ping check will attempt to ping a server.

Attributes

Metrics

remote.pop3-banner

The remote.pop3-banner check will attempt to connect to a POP3 mailbox server and verify that it responds to the connection.

Attributes

remote.postgresql-banner

The remote.postgresql-banner check will attempt to connect to a PostgreSQL database server and verify that it is accepting connections.

Attributes

remote.smtp-banner

The remote.smtp-banner check will attempt to connect to a SMTP mail server and verify that a HELO/EHLO is received.

Attributes

Metrics

Note

The following is an example alarm for cert_subject_alternative_names, where you would replace example.com with an expected host name on the certificate’s SAN list:

if (metric['cert_subject_alternative_names'] nregex '.*example.com.*') {
return new AlarmStatus(CRITICAL, 'Missing expected SAN');
}

remote.smtp

The remote.smtp check will attempt to connect to a SMTP mail server, send an email from the ‘from’ parameter, to the ‘to’ parameter, with a payload specified by the ‘payload’ parameter setting the EHLO from host to the value in ‘ehlo’.

Attributes

remote.ssh

The remote.ssh check will attempt to SSH to a target.

Attributes

Metrics

remote.tcp

The remote.tcp check will attempt to connect to a host and port, and optionally issue a banner match to ensure that the service is responding as specified. This can be used to test services that are not covered by the existing HTTP, SMTP, SSH, MySQL, etc. checks.

Attributes

Metrics

remote.telnet-banner

The remote.telnet-banner check will attempt to connect to a Telnet (or similar protocol) server and verify that an appropriate banner is received.

Attributes

Agent check types

Rackspace Monitoring supports the following agent check types.

• agent.apache check
• agent.cpu
• agent.disk
• agent.filesystem
• agent.filesystem_state
• agent.load_average
• agent.memory
• agent.mysql
• agent.network
• agent.mssql_database
• agent.mssql_buffer_manager
• agent.mssql_sql_statistics
• agent.mssql_plan_cache
• agent.mssql_memory_manager
• agent.mssql_version
• agent.plugin
• agent.redis
• agent.windows_perfos

agent.apache check

The agent.apache check will retrieve Apache HTTP server metrics

Attributes

Metrics

agent.cpu

The agent.cpu check will attempt to measure the usage of the CPU on a host.

Attributes

No fields are present for this particular check type.

Metrics

agent.disk

The agent.disk check exposes disk related metrics (service time, wait time, etc.).

Attributes

Metrics

agent.filesystem

The agent.filesystem check exposes file system related metrics (free space, used space, etc.)

Attributes

Metrics

Note

The reserved space only applies to Linux systems. It is the space saved for important root processes and possible rescue actions. In some systems the reserved space can be used for fragmentation allocation. For more information about Ext3 and Ext4: https://www.redhat.com/archives/ext3-users/2009-January/msg00026.html.

The files and free_files metrics only apply to Linux systems.

agent.filesystem_state

The agent.filesystem_state check exposes filesystem metrics for read-write/read-only system mounts.

Attributes

No fields are present for this particular check type.

Metrics

agent.load_average

The agent.load_average check attempts to measure the UNIX style load average on a host.

For more information about the commands used to get the load average, see Check the System Load on Linux.

Attributes

No fields are present for this particular check type.

Metrics

agent.memory

Attributes

No fields are present for this particular check type.

Metrics

The memory available to the system is used in three different ways:

• Used by the processese running in the system, this value is under “actual_used” metric.
• Used by the kernel, this value is not returned from the check but can be deduced.
• Not used by either the running processes or kernel, this value is under “free” metric.

For convenience, the system returns the value of used/free memory for the case of including kernel and excluding kernel so that you don’t have to do the calculation in your head.

agent.mysql

The agent.mysql check retrieves MySQL server metrics.

Note

Except for the replication.slave_running’ metric, all metrics starting with replication do not show up if there is no slave running.

If the libmysqlclient-dev package is not already present, you should install it on the host where the agent.mysql plug-in runs.

Attributes

Metrics

agent.network

The agent.network check will attempt to measure the usage of network devices on a host.

Attributes

Metrics

agent.mssql_database

The agent.mssql_database check returns metrics for a Microsoft SQL Server database.

Attributes

agent.mssql_buffer_manager

The agent.mssql_buffer_manager check returns metrics for the Microsoft SQL Server buffer manager.

Attributes

agent.mssql_sql_statistics

The agent.mssql_sql_statistics check returns metrics for the Microsoft SQL Server SQL statistics.

Attributes

agent.mssql_plan_cache

The agent.mssql_plan_cache check returns metrics for the Microsoft SQL Server plan cache.

Attributes

agent.mssql_memory_manager

The agent.mssql_memory_manager check returns metrics for the Microsoft SQL Server memory manager.

Attributes

agent.mssql_version

The agent.mssql_version check returns version information for Microsoft SQL Server.

Attributes

agent.plugin

The agent.plugin check will attempt to run a custom plugin on a host.

Custom plugins are simply executable files which report metrics via stdout. Plugins are placed on the server to be monitored at an installation path that depends on the operating system:

After the plugin has been installed on the server, create an agent.plugin check that specifies the name of the executable file so that the plugin can begin reporting metrics to the monitoring system, like any other check. If the plugin requires any command line arguments, you can specify them using the optional args array.

Attributes

Metrics

The metrics returned are defined in the plugin script. A plugin can send up to fifty unique metrics at a time.

Community Plugin Repository

A curated repository of plugins created by Rackspace Monitoring users is avaliable on GitHub. Contributions are welcome!

Note

The Rackspace Monitoring Agent is also capable of executing Cloudkick plugins, so if you are a Cloudkick user you can just drop in any existing plugin and it should just work.

Creating Custom Plugins

Creating custom plugins is as simple as writing a script that prints a status and up to fifty metrics to standard out. The format of the status line is:

status

The status string should describe whether the check was able to successfully gather metrics. It could be as simple as “success” to incidate that metrics were successfully gathered. When an error occurs that prevents metrics from being gathered, plugins should print a status that describes the error, then should exit non-zero without printing any metric lines.

The status line can be followed by up to fifty metric lines. Each line is output in the following format:

metric

The following descriptions provide information about parameter values.

Putting it all together, the output of a plugin that has successfully executed might look something like:

status Turkey thermometer returned valid response
metric internal_temperature uint32 165
metric ambient_temperature uint32 325

If the plugin failed, it might print the following before exiting non-zero:

status Turkey thermometer not responding

agent.redis

The agent.redis check will retrieve Redis server metrics

Attributes

Metrics

agent.windows_perfos

The agent.windows_perfos check returns metrics regarding windows performance data. This check is only available on Windows platforms.

Attributes

No fields are present for this particular check type.

Metrics

Hostinfo checks

Hostinfo checks are a special class of checks that run on demand.

In contrast to the remote and agent check types which enable you to schedule alarms or alerts for remote and agent-type checks and run them on a regular schedule, you cannot schedule Hostinfo checks or create alarms or alerts for them.

Create Hostinfo checks to perform tasks like the following:

• Fetch data on demand. For example, you can use a Hostinfo check to pipe data about the host to other services or applications.
• Run occasional checks to troubleshoot an issue.
• Periodically fetch data from large clusters of servers with the granularity of fetching from an individual computer. For example, use a Hostinfo check to retrieve information from a dashboard built on Kibana.
• Use in conjunction with service helper software to generate suggestions that are based on the status of a system or piece information that is required by support technicians.

The following table provides a list of the Hostinfo checks supported by the monitoring service.

Hostinfo checks supported by Rackspace Monitoring

You can use the Rackspace Monitoring API to run Hostinfo checks. To run a hostinfo check, issue the following cURL request:

Use the following cURL request to run Hostinfo checks by using the monitoring service.

curl -H 'X-Auth-Token: $token' '
https://monitoring.api.rackspacecloud.com/v1.0/
/agents/<agent_id>/host_info/<hostinfo_type>

For more information about how to work with checks using the Rackspace Monitoring API, see the Checks section in the Rackspace Monitoring Developer Guide. For more information working with Hostinfo checks, see the Agent host information.

Check status codes

This section provides a list of a set of status messages and codes that can be returned by various check types.

The following table lists the status messages for various check types and provides a resolution for the issue.