Originally published on February 09, 2022 by Sascha Neumeier
Last updated on January 23, 2024
•
20 minute read
Before we get started, this is part 1 of our two-part series on monitoring AWS environments. If you want to go directly to the hands-on guide, just click below.
👉 Hands-on guide on how to setup your AWS monitoring in PRTG
Part 1 | The Sensor types
Paessler PRTG includes six different sensor types for monitoring your Amazon Web Services (AWS) environment.
It's been a while since I last reviewed new sensors here on the blog. Our developers have been putting a lot of effort into programming new sensor types for Amazon Web Services (AWS) over the last months, and today is a chance to talk about them in more detail.
I have split the topic into two parts. The first part covers the new AWS sensor types in PRTG; including their features and benefits. In part two I will show you how to set up the new sensors in PRTG and what you need to consider when setting up AWS permissions and credentials.
So let's start with the different sensor types:
- AWS Alarm v2
- AWS Cost
- AWS EBS v2 (Elastic Block Store)
- AWS EC2 v2 (Elastic Compute Cloud)
- AWS ELB v2 (Elastic Load Balancing)
- AWS RDS v2 (Relational Database Service)
At this point in time, one or more of the AWS senors are still in a Beta state. Since PRTG version 21.1.65, you can enable the Experimental Features setting “Beta Sensors”. This makes it possible for you to try out upcoming features fresh from our labs and to provide us early feedback. To learn more about our Experimental Features setting, check out our article New handling of beta sensors in PRTG Network Monitor.
Apart from the AWS Cost Sensor (which has been recently developed anyway) all other sensor types have been fundamentally revised and you can recognize them by the suffix "v2". All our AWS sensor types are based on the newest version of the Cloudwatch SDK.
We also changed the standard scan interval of the sensors from 15 minutes to 5 minutes. This leads to more frequent updates so that the sensors collect more recent data. You can read about all the sensor-specific innovations below.
AWS Alarm v2 Sensor
The AWS Alarm v2 Sensor replaces the AWS Cloudwatch Alarm Sensor
The AWS Alarms feature allows you to monitor CloudWatch metrics and to receive notifications when the metrics fall outside of the levels (high or low thresholds) that you configure. You can attach multiple alarms to each metric and each one can have multiple actions. If you’re interested in more technical details, the AWS News Blog is at your service.
The AWS Alarm v2 Sensor monitors metric and composite AWS alarms by reading the data from Amazon CloudWatch. It will be the successor of the existing Amazon CloudWatch Alarm sensor. The sensor details show the respective alarm status. (PRTG Manual AWS Alarm v2)
🔥 Channel-specific differences
While the old sensor monitored the state of alarm, the new sensor can distinguish between composite and metric alarms and monitor them independently.
- Channels of sensors that monitor composite alarms:
a) Alarm state (also existed in old sensor) shows the overall state of alarms
b) Composite alarm can have multiple additional channels, one for each alarm it is comprised of. - Channels of sensors that monitor metric alarms:
a) Alarm state (also existed in old sensor) shows the overall state of alarms
b) One additional channel that shows the value of the metric on which the alarm was set
AWS Cost Sensor
The AWS Cost Sensor in PRTG shows the monthly and yearly costs of an AWS account, as well as forecasts for the costs. This helps you to keep an eye on your company's AWS account spending, as well as on the spending for single purpose AWS accounts. With channel limits, the sensor can individually notify you if your AWS account costs become too high (PRTG Manual AWS Cost)
Besides the included channels, you can optionally add additional types for costs and forecasts like:
- Unblended and net unblended costs, monthly and yearly
- Forecast for unblended and net unblended costs, monthly and yearly
- Amortized and net amortized costs, monthly and yearly
- Forecast for amortized and net amortized costs, monthly and yearly
This sensor has been available in PRTG for a while. For more details, read our expert Greg's article Monitor your AWS costs with PRTG.
AWS EBS v2 Sensor
The AWS EBS v2 Sensor replaces the AWS Cloudwatch EBS Sensor
✔️ Amazon Elastic Block Store is an easy-to-use, scalable, high-performance block-storage service designed for Amazon Elastic Compute Cloud (Amazon EC2). It is commonly used to build your SAN in the cloud, run relational or NoSQL databases or right-size your big data analytics engines just to name a few use cases. Find out more on how it works at aws.amazon.com.
The AWS EBS v2 sensor monitors the status and performance of an AWS Elastic Block Store (EBS) volume and will be the successor of the existing Amazon CloudWatch EBS sensor.
The AWS EBS v2 sensor supports various metrics, including BurstBalance (Average), VolumeIdleTime (Sum), VolumeQueueLength (Average), VolumeReadBytes (Sum) and more. Find the full list here: PRTG Manual AWS EBS v2
🔥 Channel-specific differences
The new sensor provides two additional channels called 'Burst balance' and 'Volume state', with 'Volume state' being the primary channel of the sensor.
We renamed these channels (old -> new):
- Total read time -> Average read latency
- Total write time -> Average write latency
- Queue length -> Average queue length
- Disk read -> Read bandwidth
- Read Ops -> Read Throughput
- Disk write -> Write bandwidth
- Write ops -> Write throughput
- Idle % -> Time spent idle
The old channels 'Total read time' and 'Total write time' showed the sum of the values between two scans. We changed this, so the new channels 'Average read latency' and 'Average write latency' now show the average of the value between two scans.
AWS EC2 v2 Sensor
The AWS EC2 v2 Sensor replaces the AWS Cloudwatch EC2 Sensor
✔️ Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers. Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction.
The AWS EC2 v2 sensor monitors the performance of an Amazon Elastic Compute Cloud and will be the successor of the existing Amazon CloudWatch EC2 sensor. It shows information like CPU credit balance and usage, disk read and write, network load and many more. Find all supported metrics plus a lot more additional info in our PRTG Manual entry for AWS EC2 v2.
🔥 Channel-specific differences
When activated in AWS console, you can see the new elements 'CPU credit balance', 'CPU credit usage' and 'CPU utilization' in the ECS v2 Sensor.
We renamed these channels (old -> new):
- Status (instance) -> Instance status
- Status (system) -> System status
The channels 'Disk read', 'Disk write', 'Read ops', 'Write ops' and 'Status' are no longer available in the new sensor.
AWS ELB v2 Sensor
The AWS ELB v2 Sensor replaces the AWS Cloudwatch ELB Sensor
✔️ AWS Elastic Load Balancing (ELB) is a load balancing service for Amazon Web Services (AWS) deployments. ELB automatically distributes incoming application and network traffic across multiple targets and scales resources according to requirements. Destinations can be Amazon EC2 instances, containers, and IP addresses, for example.
The AWS ELB v2 sensor monitors the performance of an AWS ELB load balancer and will be the successor of the existing Amazon CloudWatch ELB sensor, making it possible to monitor newer ELB types than the ELB v1 sensor could.
The AWS ELB v2 sensor supports various metrics, including ActiveConnectionCount (Sum), ActiveFlowCount (Average), ConsumedLCUs (Sum), UnhealthyHostCount and a lot more. Find the full list of metrics including a lot of other details in our PRTG Manual entry for AWS ELB v2.
🔥 Channel-specific differences
The old sensor only supported classic load balancers which have been discontinued by AWS. The new sensor supports application balancers (which replaced the classic load balancers) and network load balancers. The network load balancers were designed anew since they did not exist when the old sensor was created. The old sensor and the new application load balancer sensors have some differences:
We renamed these channels (old -> new):
- Healthy hosts -> Healthy host count
- Unhealthy hosts -> Unhealthy hosts count
- HTTPCode Backend 4xx -> Target 4xx count
We added the channels 'Consumed LCUs', 'Processed bytes', 'Rule evaluations' and 'ELB 4xx count' to the new sensor. We removed the channels 'HTTPCode Backend 2xx' and 'HTTPCode Backend 5xx'.
AWS RDS v2 (Relational Database Service) Sensor
The AWS RDS v2 Sensor replaces the AWS Cloudwatch RDS Sensor
✔️ Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the AWS Cloud. It provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks. For examples on how to create and connect to a database instance using AWS RDS, switch to aws.amazon.com and read on here.
The AWS RDS v2 sensor monitors the performance of RDS (Relational Database Service) instances and will be the successor of the existing Amazon CloudWatch RDS sensor.
The AWS RDS v2 sensor supports various metrics, including BinLogDiskUsage (MB), CPUUtilization (Average), DatabaseConnections (Count), FreeStorageSpace (MB), Network Throughputs and a lot more. Find the full list of metrics including a lot of other details in our PRTG Manual entry for AWS RDS v2.
🔥 Channel-specific differences
When activated in AWS console, you can see the new elements 'CPU credit balance', 'CPU credit usage' and 'CPU utilization'.
We renamed these channels (old -> new):
- DB Read -> Read Throughput
- DB Write -> Write Throughput
- Network In -> Network Receive Throughput
- Network Out -> Network Transmit Throughput
- Read OPS -> Read IOPS
- Write OPS -> Write IOPS
You'd like more AWS sensors? Give us feedback!
Would you need additional sensor types, e.g. to monitor your Cloudfront network or application integration like Amazon MQ or EventBridge? Sensors like these can be useful in different scenarios, including industrial or building automation settings or even other scenarios.
To provide the best solution possible, we need to understand your use cases better. For this we have prepared a short survey. You will only need a few minutes: click this link and our devs will be ecstatic. 😊
Okay, so much for the theoretical part one. As promised, we will go into practice in part two. Do you already have questions up to this point? Then by all means ask them! Either directly here in the blog as a comment, or contact our support via email.
Either way, we are looking forward to hearing from you!
See you soon in our second part on AWS monitoring, a "Hands-on guide on how to setup your AWS monitoring in PRTG".
You there!
