Diagnostic Tools

“Why is my check failing?”

It isn’t always obvious what’s causing the failure when a check does ‘down’ and additional information about what our probes are experiencing can be helpful. For example, if your website is timing out, is it the web server, a DNS problem, or maybe packet loss on the network?

Our new diagnostic tools allow you to run several utilities on our probes and give visibility to what our probes are seeing to help you troubleshoot a failing service. These tools can be useful to narrow down where the failure is so you can get things fixed and services restored as quickly as possible.

Tools available:

  • Ping
  • Traceroute
  • MTR
  • Dig
  • Page Load (browser loading with page speed – HAR viewer)
  • Screenshot

More information about the tools and some troubleshooting advice can be found in our documentation.

You can find these tools on the “Diagnostic Tools” tab when you login to your NodePing account.  If you don’t yet have a NodePing account, you can create one and try out these tools with our 15-day, free uptime monitoring trial.

What other tools would be helpful on that page? Let us know in the comments.

Monitoring Memory Usage in Node Applications

I recently started a new node.js project that stored a good bit of data in memory, and talked to clients over web sockets as well as providing a REST interface. The combination of components meant there were several spots that I wanted to monitor.

For the WebSockets, I hooked up NodePing’s WebSocket check. In this case, I didn’t need it to pass any data, just connect and make sure the WebSocket interface was accessible. This was a quick win, and in seconds I was monitoring the WebSockets interface of my new app.

One of our concerns with this particular application was how much memory it would use over time, since it retains quite a bit of data in memory for as long as the server is running. I was curious about how much memory it would end up using in real use. I was also concerned about any memory leaks, both from the data caching and the use of buffers as the system interacted with WebSockets clients. This called for monitoring memory usage over time and getting notifications if it passed certain thresholds.

To accomplish this, I used NodePing’s HTTP Parse check. In my node app, I created a route in the REST interface that would return various statistics, including record counts in the cache and a few other things I was curious about. The key piece for monitoring purposes, though, was the output from the node.js process.memoryUsage() call. This gives me a nice JSON object with rss, heapTotal, and heapUsed numbers. This was in combination with some other stats I wanted to capture, and the output looked something like this:

  "server": {
    "osuptime": 22734099.6647312,
    "loadavg": [
    "freemem": 1883095040,
    "processmem": {
      "rss": 77959168,
      "heapTotal": 63371520,
      "heapUsed": 30490000

Next I added an HTTP Parse check in NodePing, and added the rss and heapUsed fields to the check. For the check setup, we use JSONPath syntax, so the full fields looked like this:

At first I was a little startled by the results of this. The rss figure is consistently a good bit higher than the heapUsed number, and it climbs slowly over time. At first glance this looks like the system has a memory leak. However, it turns out this is normal for node.js applications. Node manages the memory used internally, and the rss figure shows what’s been allocated at some point and is still reserved, but not what’s actually in use. The heapUsed figure, on the other hand, does reflect Node’s periodic garbage collection.

I found the HTTP Parse check to be perfect for watching memory usage and checking for a memory leak in my Node application. The key was capturing the heapUsed as reported by Node. In my case I had the check grab this information once a minute, and I quickly had a handy chart showing the total memory usage of my application over time. As a result, trends become quickly apparent and I can see how my memory usage grows and shrinks as Node manages its memory usage.

Since I was hitting the REST interface of my application once a minute to collect the memory information, this had the side benefit of notifying me if the REST interface ever goes down. If I wanted to chart the REST interface’s response time, I’d add a separate HTTP check.

At NodePing, a lot of what we’ve built originated in our own experiences building and supporting Internet-based services. This is another example of how we have used our own monitoring systems internally to help us build and maintain our own systems.  If you  and haven’t tried out NodePing’s monitoring, check out our 15-day free trial.

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:
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.