PUSH Checks – Heartbeats and Metrics Monitoring

One of the most requested features we get is the ability to push monitoring results into NodePing. Today, we make good on all those requests and are happy to announce our latest check type, PUSH.

Unlike our other checks, PUSH checks allow your server to push metrics into our system, track the metrics, and receive alerts based on the results. This significantly adds to your ability to monitor services that are not Internet accessible, and monitor additional custom metrics. Our customers running LANs can now get heartbeats and metrics on internal servers like Windows AD controllers. Or, you can monitor metrics that are only relevant to your systems in ways that are specific to your environment. We’ll track and alert on any metric you want to push at us!

Heartbeats and Metrics

PUSH checks are configured to send results on a specific interval and you can configure the check to fail if we haven’t received a pushed result from you. This is the heartbeat functionality.

You can also push us a data payload of metrics with the PUSH check result and configure your check to track those metrics. The check will fail if any configured metric is missing or if the values in the result are outside your configured min/max range.

Metrics are great for keeping an eye on system load, disk free space, or any other service or system metric you can gather on a server and send to us.

PUSH checks are flexible and can be configured to be heartbeat-only, metrics-only, or both.

PUSH Clients

To send us your result (heartbeat or metrics), you’ll need to submit an HTTP POST to NodePing with information about the check and optionally the metrics. Details can be found in our in our PUSH check documentation.

We’ve got fully-functional, open-source clients in Python2, PowerShell, and POSIX script available on our GitHub public repo that have been tested with the following OSes:

  • CentOS 5 (Python2 and POSIX)
  • CentOS 6 (Python2 and POSIX)
  • CentOS 7 (Python2 and POSIX)
  • Debian 9 (Python2 and POSIX)
  • Devuan 2 (Python2 and POSIX)
  • Fedora 28 (Python2 and POSIX)
  • FreeBSD (Python2 and POSIX)
  • OpenBSD 6.3 (Python2 and POSIX)
  • OpenSUSE LEAP 15 (Python2 and POSIX)
  • Raspbian STRETCH (Python2 and POSIX)
  • Ubuntu 14.04 (Python2 and POSIX)
  • Ubuntu 16.04 (Python2 and POSIX)
  • Ubuntu 18.04 (Python2 and POSIX)
  • Windows server 2012 (Python2 and powershell)
  • Windows server 2016 (Python2 and powershell)

Download a client and follow the instructions in the client README.md file to set up your PUSH client.

An example of the default metrics sent from our POSIX client:

OS load: 1 minute, 5 minute, and 15 minute load stats
Memory free in MB
Disk space free in percentage by mount point.

There are also optional modules for Redis, Cassandra, ZFS, iptables, and more.

All our clients are built so you can add your own modules to push additional metrics – the ones you care about. The requirements for pushing metrics into our system are fairly simple, so you can write your own scripts in your preferred language. It just needs to output JSON data with numeric values. You can find the information you need to create your own client modules in our PUSH check documentation and take a look at existing modules for examples.

We encourage pull requests for new modules so if you build something you think others would find useful, please do share.

We’re working on new reports and dashboards to visualize metrics, making the new PUSH check even more useful, so keep an eye out here on the blog for those announcements.

If you aren’t using NodePing yet, you can sign up for a free, 15-day trial and test out our new PUSH checks yourself. We think you’ll love the new functionality along with our rock-solid monitoring and fast/accurate notifications.

Public status reports updated

We announced the initial release of our public status pages for our web site and server monitoring service a couple of weeks ago. These pages allow you to have a public status page for all of your servers and websites in one place. Since then, we’ve worked to add some additional enhancements that we think will be particularly useful.

First, we’ve added custom domains. This allows you to set up a URL such as https://status.example.com as your public status page. Just add a cname record to your DNS to point the domain to nodeping.com, and add the domain or subdomain to the report settings in your NodePing account (under Account Settings -> Reporting), and the custom URL will be available within 30 seconds or so. Once you have a custom domain set up, all of your public reports are available on that domain.

We’ve also added links to reports on individual check results. Any checks for which you have enabled public reports will include a link on the status page to go to the individual report. At the same time, we tweaked the individual results report so that the long list of results only shows if you click on the “Show Details” button. We got some feedback that the whole list is a little overwhelming, so we’ve made the information still available but not shown by default.

Finally, we’ve made a few cosmetic tweaks to the reports and to the reports settings page.

We have a number of additional features and enhancements we’re planning to add to these reports still, but we hope what we’ve done so far is already useful to everybody. As always, feedback and suggestions are welcome. Let us know what you think at support@nodeping.com, by posting comments here, or by using our Contact Page.

Public Status Pages

One of the frequent requests we get is for a public status page that lists the status of several server monitoring checks in one place. There is a lot to this particular feature, but we’re pleased to announce that the first version of this feature is now available on NodePing.

NodePing Status ReportThe status report allows you to select any of your active checks for listing on the status page. Any number of checks can be included. Just go in to the Reporting tab under Account Settings and select the checks you want to have displayed. The tab also shows the URL for your status report page.

The report has a “title” field, which is displayed at the top of the page. This field supports HTML, so you can add tags to style the look of the top of the page. That includes using an img tag to show your logo or other branding type information at the top of the page. For examples, you can look at https://nodeping.com/reports/status/MTSL1PQUZC and https://nodeping.com/reports/status/P9H0LI94W7. Script tags and other cross site scripting will be filtered. Provider accounts have additional control over the look of the page using the site branding features.

We didn’t want to just start publishing information without allowing people to opt-in to this featuer, so by default this report is not enabled. Enabling it is just a few clicks.

There are a number of additional features that we plan to add to this report, including more customization, links to individual check result pages, and custom URLs. In the meantime, feedback and suggestions are always welcome at support@nodeping.com.

HTTP Parse Check – Monitor Anything!

Most of the checks that we have released for NodePing to date have monitored specific Internet-based services. These are very useful, and they are the bread and butter of traditional web site and server monitoring services. Today we’re really excited to announce the release of our “Monitor Anything” check. You can use it to monitor… well, just about about anything.

The new check is the HTTP Parse check. It connects to a remote HTTP service and parses the response for specific fields and values. The values are then stored in the check results for reports. If any of the values are outside of your configured ranges, it triggers a notification via email, SMS, twitter, voice call, or webhook.

The HTTP Parse check can look for named fields in text or a JSON response. For example, if the check is configured to look for a field named “llamas” and the response contains llamas: 34 then the system will store 34 as the value, which will be displayed on reports and charts.

Similarly, the response could be in JSON format. For example, the JSON could be something like this: {"animals": {llamas": 34}} Configuring the check to look for animals.llamas will store 34 in the check results. The check can handle multiple fields, as long as they are all accessible from one request to a URL, and it can pull values from the middle of a larger response.

What could this check be used for? Anything that is accessible by an HTTP request that returns a field with a numeric value. Since it is parsing the response for the field name and value, it can be embedded in other data. This means that any JSON API or data service on the Internet is potentially a target for this.

Sample Server Load OutputOur use of this check at NodePing is to monitor server health. As you can imagine, running a service like NodePing means we have a number of servers all over the place. We use this check to monitor server load, free memory and disk space on a number of our servers.

There are many ways to generate the system information from a host so it can be used for this check. Some of the ones we’ve tried include Linfo and phpSysInfo. We wanted a similar tool written in Node.js, so we wrote npsystats, which is what we now use for our systems. We’ll have more to say about npsystats in the near future. There are a number of other similar tools out there, such as Ohai in Ruby. The HTTP Parse check is capable of working well with most of them.

For example, we have a check on a web server that monitors server load. npsystats returns the following json in response to the check’s HTTP GET request:
{"load":{"1min":1.86376953125,"5min":0.9501953125,"10min":0.64404296875}}
The check is set to watch three fields: load.1min, load.5min, load.10min, with a range of 0 to 8 (it could be different for each field, but it doesn’t have to be). So if the load on this server goes over 8, I will get an email. I also can access a graph showing the 1, 5, and 10 minute load for this server.

More information can be found in our documentation for the HTTP Parse Check. We think this makes NodePing an even more awesome piece of your system monitoring and automation toolkit, particularly when tied to judicious use of notifications and webhooks. If you don’t have an account on NodePing yet, try it out with our 15 day free trial.

Don’t let your certificate expirations catch you offguard

Microsoft’s recent slipup with a certificate that caused outages for the Azure service is a reminder for the rest of us to make sure we are keeping a close eye on certificate expirations. Having a certificate expire on you makes you company look really inept, but in practice keeping track of certificates and when they expire can be a pain if you are trying to do it manually. A system that monitors certificates and reminds you before they will expire can be an excellent way to avoid having this happen to you, and is much easier than tracking them in a spreadsheet or sticky notes.

NodePing provides a few different ways to keep ahead of certificate expirations. For web servers, we have an SSL Check specifically designed to check the validity of SSL certificates and warn you a set number of days before they expire. You can set the number of days to anything that is useful for you. We typically suggest a couple of weeks in advance of the expiration.

Certificate expirations can also hit other types of services as well. Our email checks (SMTP, POP, and IMAP) can verify the SSL/TLS certificates used by each of these servers. Similar to the SSL check for web services, these checks verify that the SSL certificate is valid and working, and also can be set to warn you a certain number of days before they expire.

Tracking your certificates can be a pain, but it doesn’t have to be. Using an automated monitoring system like NodePing for SSL Certificate monitoring can make the task easy and painless, and let you focus on more interesting things.

SIP Monitoring

If you run SIP servers, you’ll be pleased as punch to know we’ve just released a new SIP server monitoring check just for you. Now you can be alerted if your SIP server goes offline or isn’t responding to SIP commands.

SIP stands for “Session Initiation Protocol,” and refers to a signaling protocol that can run over TCP or UDP and is commonly used for voice and video communications. SIP servers are often the connection points for VOIP calls.

The check does not initiate a call, but rather tests that the the server accepts a SIP connection by sending the OPTIONS command and watching for the response. Even if your server does not support the OPTIONS command and returns an error, this indicates that the server is up and operating, so the check succeeds. You can find more information about this check in our SIP Check documentation.

This new SIP check is available today for all NodePing accounts. If you don’t have a server monitoring account with NodePing yet, head on over and sign up for our free 15-day trial.

Introducing NodePing’s Monitoring API

This is Part 1 in a series of posts we’ll have in the coming weeks detailing various aspects of NodePing’s new API. The API allows customers to manage most aspects of their site and server monitoring through an HTTP accessible RESTful interface. It provides list, read, write, and delete functionality for subaccounts, contacts, contact groups, and checks, as well as allowing you to retrieve checks and notifications. Access to the API is included in our service at no extra cost.

The API supports HTTP methods for most calls:

  • GET for listing or retrieving specific records,
  • PUT to update a record based on its ID,
  • POST to create new records (IDs are assigned automatically), and
  • DELETE to delete records.

All responses are JSON.

The API’s authentication is token based. You can find your token in the Account Settings area of your account, or if you’re logged in to the service it is also displayed on the Documentation page.

Documentation is available at https://nodeping.com/API_Documentation. Reference docs showing all supported calls are at https://nodeping.com/API_Reference.

Here’s an example of updating a monitoring check:
curl -X PUT -d'json={"threshold":4, "target":"http://www.example.com/index.html", "enable":"true", "notifications":[{"SKTUSP":"Days"}]}' 'https://api.nodeping.com/api/1/checks/201205050153W2Q4C-1FOC0YYM'

The response to that call would look something like this:

{
  "_id": "201205050153W2Q4C-1FOC0YYM",
  "_rev": "4-5069940f2a95fc6ae5564e329da755bd",
  "customer_id": "201205050153W2Q4C",
  "label": "Site 2",
  "interval": 1,
  "notifications": [ { "SKTUSP": "Days" } ],
  "type": "HTTP",
  "status": "modified",
  "modified": 1337744587374,
  "enable": "active",
  "public": false,
  "parameters": {
    "target": "http://www.example.com/index.html",
    "threshold": 4,
    "sens": "2"
  }
}

Since the API is brand new, we would really like to hear from people who start using it in real situations. Please let us know what works well, and what we could do to make interacting with the API easier.