Getting Started with RDS Health Checks
We’re excited to announce the first of our CloudWatch integrations: RDS. Among Opsee users, RDS is the most common AWS service apart from EC2, and it’s more popular than running RDBMS on EC2 instances–it seems not running a database is becoming a popular choice among dev teams.
While we’re not the first monitoring company to offer a CloudWatch integration, there are a few reasons why we believe ours is better.
One check per target, for all metrics
We want to consolidate your notifications as much as possible. With Opsee, you don’t have to create a health check for each and every metric you think is important. Create one check for each RDS Database Instance, and add as many metrics as you’d like to the check. This is an early effort toward a much larger project here, which you’ll hear more about later.
Interactive Threshold Setting
When you’re setting up thresholds on your metrics, we show you the last hour of data for context and let you see the impact of your thresholds as you’re setting them.
Automatic health checks for each DB instance
When you activate Opsee, we’ll automatically create a health check for each of your database instances, with the following assertions:
- CPU Utilization < 95%
- Database Connections < 90% of max for instance size
- Freeable memory < 10% of instance memory
We’re able to determine the max connection count and memory for each of your instances, so we do these calculations for you.
Recommendations
A couple other specific metrics you’ll likely want to notify on, if you have them, are:
- Replica lag — Monitoring replica lag can be an effective way to ensure your MySQL replicas are within an appropriate range of tolerance.
- ReadIOPS, WriteIOPS — If you’ve chosen to use provisioned IOPS for your RDS backing storage, you can monitor how effectively those IOPS are being used or if you are ever hitting your provisioned limits.
Happy databasing.
