Probe Server IP Address Changes – [LD, ES]

Our probe servers in the following locations will be changing IP addresses on 2014/09/23:
LD will change from 78.157.217.106 to 87.117.200.68
ES will change from 94.46.242.178 to 185.4.92.30

No data loss is expected.

Please adjust your firewalls appropriately so your checks do not fail because of the probe IP addresses changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ.

[UPDATE – 2014-09-23 08:04GMT-6] – IP change for LD and ES are complete

Adding Probes to North America and Europe along with an IP Change [BR]

NodePing continues to grow!
We’re adding two new probes in the North America region one to the Europe region.

Las Vegas, Nevada (US) – NV (208.66.75.231)
Seattle, Washington (US) – WA (162.210.249.48)
Madrid, Spain (ES) – ES (94.46.242.178)

In addition, we have one IP change to our current probe in Brazil:
BR will change from 177.54.149.101 to 177.67.81.184

These changes will take place 2014-07-02. Please update your firewalls appropriately.

As always, a current list of all the IP addresses for our probe servers can be found in the FAQ.

[UPDATE – 2014-07-02 09:48GMT-6] – New probes are online and IP change for BR complete

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.

Heartbleed Statement

Many of you are scrambling to mitigate the Heartbleed SSL vulnerability (CVE-2014-0160) with your list of vendors and services. You can check NodePing off that list.

NodePing’s SSL services (including our website, user interfaces, API, and client checks) were all unaffected by the Heartbleed vulnerability.

Our application and service is based on Node.js and in a stroke of dumb luck or serendipitous genius the core developers had chosen over a year ago to disable the ‘heartbeat’ functionality in the Node.js implementation of SSL. Thank you, core devs!

Please contact support if you have any further questions.

IP Address Changes – [DE, CA]

Our probe servers in the following locations will be changing IP addresses on 2014/04/14:
CA will change from 23.94.101.96 to 162.211.65.254
DE will change from 130.255.191.151 to 94.249.196.145

No data loss is expected and no action by you is required.

Please adjust your firewalls appropriately so your checks do not fail because of the probe IP addresses changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ.

[UPDATE – 2014-04-14 08:52GMT-6] – IP changes complete

New Latin America Region

We’re excited to announce we’re adding a new check region and probe servers in Latin America to the NodePing server monitoring service.
The new region will be brought online and available for selection starting April 2, 2014. With this new addition, NodePing now has four distinct check regions, North America (NAM), Europe (EUR), East Asia/Oceania (EAO), and Latin America (LAM).

The new probe servers are located in:NodePing probe map

  • Panama [PA]
  • Curico, Chile [CL]
  • Federal, Argentina [AR]
  • São Paulo, Brazil [BR]
  • Miami, Florida, USA [FL]

Some may be asking “Why is Miami included in the Latin America Region?”. Geography was never our strong subject, but we do understand Miami is in North America. Significant traffic within different parts of Latin America goes through Miami, especially between Central America and South America, so we wanted to ensure that was covered for our Latin American customers.

You can specify our new Latin America region as the default region on your account or select it as a location on individual checks to get results from these new probe servers.

IP addresses for the probe servers can be found in the FAQ. Any questions can be directed to support(at)nodeping.com

[UPDATE – 2014-04-02 08:20GMT-7] – All new Latin America probes are online.

Public Status Report Update

NodePing’s public status report feature allows you to create an uptime report for your sites or services in your own domain. It’s a popular part of our website and server monitoring service, and is available on all NodePing accounts. Today we added a couple of (hopefully very useful) enhancements to the public status reports.

The report now has a column on the right side that shows the uptime for each service over the past 30 days. It also allows you to display a column to show the check type, which can be turned on and off in the report’s configuration page. Plus, we’ve also tweaked the filtering on the title field, which has opened it up to a wider degree of customization. For example, you can include image tags and style tags in this field, which allows you to add your logo, as well as having significant control over the overall look of the report.

The report already gave you the ability to set which checks should appear on the report, and to set a custom URL for the report (so, for example, you could have it on the status subdomain of your own domain, so the URL would be status.example.com). And if you have public reports turned on for individual checks, those reports will automatically be linked from the status report.

We hope that these enhancements, on top of the features we already had for the status report, will make this report very useful to all of our customers. We put a lot of emphasis on feedback from our users, so please let us know what other features would help you make the most of our monitoring service.

If you run web sites or other Internet services and haven’t tried out our monitoring service, give us a try with out 15 day free trial.

Follow

Get every new post delivered to your Inbox.

Join 46 other followers