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": [
      0.17041015625,
      0.09814453125,
      0.12451171875
    ],
    "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:
server.processmem.rss
server.processmem.heapUsed

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 Advanced Check

Our HTTP checks for website monitoring at NodePing already include our standard HTTP Check, the HTTP Content Check that lets you verify that specific content is present or is not present in the page, and the HTTP Parse Check that allows you to track and alert on arbitrary data points in the response. Today we’re excited to announce that we’re adding the HTTP Advanced Check to our HTTP line up.

The new HTTP Advanced Check adds the following capabilities:

  • simulate a form POST to your web site and verify the expected response
  • check for arbitrary HTTP response status codes for custom API servers
  • send HTTP headers
  • verify specific HTTP headers are being received
  • send PUT, DELETE, HEAD, TRACE, or CONNECT methods

This will allow you to do more in-depth monitoring of your HTTP services. Use cases may include:

  • POST incorrect credentials to log in pages and verify the HTTP status code of 403 is returned.
  • Send mobile browser User-Agent headers and use the content checking to verify the mobile version of your site is being shown
  • Verify a PDF link is returning a PDF file by checking the return header for the correct ‘Content-Type’:’application/pdf’
  • Verify your redirect script is returning a 302 status code and not an error.

Additional information about this new check type can be found in our documentation.

The HTTP Advanced check is now available on all NodePing accounts. All accounts also include unlimited notifications, including international SMS. If you don’t have a NodePing account yet, please sign up for our free 15-day free trial.

Minor API enhancements added today

We have a couple of updates to our API.

You can obtain the current status of your checks using /api/1/results/current. This returns a list of checks that currently have an “event,” which means that the check is currently disabled or is listed as “down.” The information returned will include a timestamp when the event started. Checks not listed in the results for this call are currently “up.”

We’re also adding a couple of convenience tweaks. When you are getting a list of checks, you can add a “current” parameter in order to have any current events added to the check information. This basically mixes the information from the “current” call mentioned above in with the list of checks.

Additionally, when you are getting a single check, you can add a “lastresult” parameter to the request and get the most recent result for that check along with the check information.

All three of these changes are included in our API Reference documenation. Hopefully these minor enhancements will be of help. Feedback is welcome here or at support@nodeping.com.

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.

RBL Monitoring

What better way to top off our email monitoring enhancements than with a new check type! We’re happy to introduce our RBL check.

RBL, or DNSBL, stands for “Real-time Black List,” and is used to publish the addresses of computers or networks linked to spamming, malware, or other abuses which system administrators may want to block from accessing their networks.

There are hundreds of RBLs in existence, which use a wide array of criteria for listing and delisting of addresses. These may include listing the addresses of zombie computers or other machines being used to send spam, listing the addresses of ISPs who willingly host spammers, or listing addresses which have sent spam to a honeypot system.

If the IP addresses of your servers appear on these RBLs, there’s a good chance you’ll have difficulty interacting with networks that subscribe to these RBLs. For instance, if your SMTP server is listed, you’ll likely be unable to send email to the systems that use the RBL you are listed on.

You can use our new RBL check to ensure that your servers aren’t listed and to receive notifications if they do get listed, allowing you to quickly take steps to remove your addresses from those RBLs. You can find more details about which RBLs we check and how to set them up in our RBL Check documentation.

Adding RBL checking to our already robust email monitoring checks for SMTP, POP3, and IMAP4 will help you sleep at night knowing that email is flowing as it should be.

RBL monitoring checks are available to all NodePing accounts. If you don’t have an account yet, you can sign up for your free 15-day trial of our server monitoring service.

POP Monitoring Enhancements

As part of strengthening our email server monitoring solutions, we’ve added a bunch of new features to the POP3 check type. They nicely complement our recent changes to our SMTP and IMAP checks.

New features include:

  • Non-standard ports. Specify any port, not just POP default port 110
  • SSL/TLS support on any port – not just 995.
  • SSL certificate validation
  • SSL certificate expiration warnings – configurable to X days before expiration
  • User login verification.

More details about the new POP server monitoring enhancements can be found in our documentation.

These features are available to all NodePing server monitoring accounts today. If you don’t have an account yet, you can sign up for a free 15-day trial at https://nodeping.com.

Now, if you just had a way to monitor spam blacklists for your server ip addresses… RBL Check is on its way!

Follow

Get every new post delivered to your Inbox.

Join 35 other followers