How 2wav Monitors Web Applications in the Cloud - Part 2

In part one of this series, we covered setting up monitoring for your web application. However, that's just the beginning.

A second level of monitoring should take place at the application stack level. At this level, we start paying attention to the applications that keep your web app running.

At 2wav, we run a number of Meteor application behind an NGINX web server with a MongoDB database. We make sure that our Meteor, NGINX and Mongo applications are all doing their job. Let’s take a look at how this can be accomplished.

Process Monitoring

When setting up monitoring of your application stack, it's important to know the pieces that keep your application running. If you’ve built the application, then you’ll know exactly what those pieces are. If you're using an application build by a third party, then you may want to take a look at what components keep it running. You can do this by consulting the documentation, or using the quick and dirty method of checking what’s running on your server using the process listing.

Meteor, Mongo, and NGINX are key application components for many of our deployments here at 2wav. Our Meteor apps have startup scripts, which are named according to the application they run. We use the Sensu Process Checks plugin to ensure that key processes are always running. The plugin may be configured to look for one or more instances of a process, and notify if the number of instances drops below or climbs above an acceptable threshold.

Is It Actually Up?

Monitoring your server and application stack will ensure that all the things necessary for your application to run are in order. However, it does not follow that your application is necessarily running. A bug at your application stack level may cause your app to crash and respawn rapidly, too quickly for your monitoring tool to realize that it’s down. Or your web server may be running, but unable to communicate with the application that it proxies. Or maybe it’s nothing within your control, such as a DNS server failure somewhere between your users and your web application.

This is where a third level of monitoring comes in. At this level you ask "is my application actually running and accessible to my users?" Monitoring your application’s URL endpoints will help to answer this question. This is the equivalent of opening your browser and typing in the URL for your application to see if it loads, except that you have your monitoring tool do this for you at regular intervals.

In addition to checking if your application loads on a given URL, many monitoring tools also allow you to check how quickly your application loads, and will notify you of slow page loads or timeouts. Some will also check the expiration date on your SSL certificates, and warn you when it’s close to expiration.

To verify that our apps are up and running, we use HTTP endpoint monitoring provided by Sensu HTTP plugins. Using this plugin we make calls at regular intervals to our web application URLs, and notify if the server can’t be reached, or if the call times out. Such monitoring is a great catch all for anything that may be missed along the way, such as a metric that may result in your application remaining online but being slow. If the failure to connect to the application isn’t for an obvious reason, investigations of the core reason may provide insight into other metrics that you should be monitoring.

In our final installment we'll look at monitoring the things that are our of your control, but still have a direct impact on your applications—your infrastructure provider. We will also provide some recommendations for keeping alert traffic to a minimum to avoid alert fatigue.