Application Monitoring

Once you have an App running on Convox, setting up monitoring can help you keep it running smoothly. As a starting point, the following baseline monitoring coverage is recommended when using Convox:

1. Set up availability monitoring to be notified if your App stops responding.
2. Create a CloudWatch Dashboard to help track multiple metrics of your App.
3. Create CloudWatch Alarms to be notified of critical changes to your App's metrics.
4. Track CloudWatch Metrics to keep tabs on your database, etc.

Set up availability monitoring

Let's say your App runs at example.com. By having a third-party service like Pingdom send an HTTP request to example.com at frequent intervals, you can ensure that you'll be notified as soon as part of your system fails. Whether you are having problems with your infrastructure, database, web application, or DNS, simple availability monitoring can be used to help you catch many major problems quickly.

We recommend using an availability monitoring service not run on AWS so that an AWS outage doesn't leave you blind to the problem.

Further Resources

• Datadog: Introducing Availability Monitoring
• NewRelic: Downtime alert settings
• Pingdom: How to set up an uptime (HTTP) check

Create a CloudWatch Dashboard

Sometimes it's hard to diagnose a problem without stepping back and looking at the bigger picture. By creating a CloudWatch Dashboard that tracks multiple metrics of your application over time, you can spot abnormalities, warning signs, bottlenecks, and more.

To set up a CloudWatch Dashboard with a single widget that tracks CPU and memory utilization of a given App, follow these instructions:

1. Visit your CloudWatch console and navigate to Dashboards.
2. Click the "Create Dashboard" button.
3. Enter a name for the new dashboard. Consider <rack-name>-<app-name>, e.g. production-site.
4. Select the "Metric graph" widget type.
5. From the ECS Metrics category, select "ClusterName,ServiceName."
6. Select the CPUUtilization and MemoryUtilization graphs for the Service you'd like to monitor. For example, if you wanted to monitor the web process of a foo-bar app that is running in your production Rack, the service name would look like production-foo-bar-ServiceWeb-B3YF4EMQCN89.
7. Click the "Create widget" button.
8. Consider resizing the widget (by dragging the bottom right corner) for better readability.

Create CloudWatch Alarms

If, in addition to being able to monitor your new CloudWatch Dashboard, you'd like to be notified any time a certain metric enters a specific range of values, you can set up a CloudWatch Alarm. For example, if you want to be emailed when your App exceeds an average CPU utilization of 95% for a period of 30 minutes, you could set up that CloudWatch Alarm by taking the following steps:

1. Visit your CloudWatch console and navigate to Alarms.
2. Click the "Create Alarm" button.
3. From the ECS Metrics category, select "ClusterName,ServiceName."
4. Select CPUUtilization for the Service you'd like to monitor. For example, if you wanted to monitor the web process of a foo-bar app that is running in your production Rack, the service name would look like production-foo-bar-ServiceWeb-B3YF4EMQCN89.
5. Click the "Next" button to move to the "Define Alarm" step.
6. In the Alarm Threshold section, specify a name like "High CPU utilization," and then fill out the inputs to complete the phrase, "Whenever CPUUtilization is > 90 for 2 consecutive periods."
7. In the Actions section, next to "Send notification to:," click "New list," then enter a new notification list topic name and the email addresses that should be notified. Note that this will result in the creation of a new SNS Topic.
8. In the Alarm Preview section, confirm that Period is set to "15 Minutes" and the Statistic is "Average."
9. Confirm that you see your new Alarm listed with State "OK."

Note: A notification email sent by a CloudWatch Alarm can be used as a trigger for other services like PagerDuty. See their Email Integration Guide for more information.

Track CloudWatch Metrics

Once you've created a CloudWatch Dashboard, you can configure additional CloudWatch Metrics and add them to a dashboard as widgets. Let's say you want to keep an eye on the swap usage of your PostgreSQL RDS instance, so you know when to upgrade to a larger instance type. You could add a widget displaying that usage to a dashboard by following these steps:

1. Visit your CloudWatch console and navigate to Metrics.
2. From the RDS Metrics category, select "Per-Database Metrics."
3. Select the SwapUsage Metric Name for the desired RDS instance.
4. Click the "Add to Dashboard" button.
5. In the "Add to Dashboard" dialog, select the desired dashboard and click the "Add to Dashboard" button.
6. Consider resizing the widget (by dragging the bottom right corner) for better readability.

Container Insights

The dashboards, alarms, and metrics described above are built from the standard ECS metrics that CloudWatch publishes for every Rack. CloudWatch Container Insights extends that coverage with higher-resolution, per-Service metrics (CPU, memory, network, and task counts) and a set of prebuilt dashboards, without installing or maintaining any additional tooling.

Container Insights is controlled by the ContainerInsights Rack parameter. It defaults to No. Enable it on a Rack with:

$ convox rack params set ContainerInsights=Yes

This is an in-place change to the ECS cluster setting. CloudFormation updates the cluster's containerInsights setting from disabled to enabled and the cluster is not replaced, so running Services are unaffected. After the update completes, Container Insights metrics and the automatic dashboards appear in the CloudWatch console under the ECS cluster, which is named after the Rack.

Container Insights is a paid CloudWatch feature. Expect roughly 15 to 25 USD per month per Rack depending on the number of Services and tasks. It is billed separately from the standard ECS metrics, which remain free.

Coverage applies to Fargate workloads on the Rack. Services that run on EC2 instances need the CloudWatch agent running as a daemon on the instances to report container-level metrics, which is a follow-up step beyond enabling this parameter.

To turn the feature off again, set ContainerInsights=No. This reverts the cluster setting to disabled and stops the associated CloudWatch charges.

See Also

• Logs
• Debugging
• Rack Updates
• Reference: AWS