EC2 CloudWatch metrics don't match what Top shows

Question

I have a t2.micro EC2 instance running on a processor of about 2%. I know from other posts that the CPU usage shown in TOP is different from the CPU registered in CloudWatch, and should be trusted with the value of CloudWatch.

However, I see very different values ​​for memory usage between TOP, CloudWatch and NewRelic.

There 1 GB of RAM per instance, and TOP shows ~ 300 MB of Apache processes, plus ~ 100 MB of other processes. The total memory usage reported by TOP is 800 MB. I assume that 400 MB OS / system operating resources?

However, CloudWatch reports 700 MB of usage, and NewRelic reports 200 MB of usage (even if NewRelic reports 300 MB of Apache processes elsewhere, so I ignore them).

CloudWatch's memory frequency often exceeds 80%, and I would like to know what the actual value is, so I know when to scale, if necessary, or how to reduce memory usage.

Here's a recent memory profile, it seems that something is using more memory over time (the big failures are restarting Apache or maybe GC?)

Screenshot of memory usage in the last 12 days

Answer 1

AWS does not support the memory metrics of any EC2 instance. Because Amazon performs all of its observations outside the EC2 instance (servers), it is not capable of capturing memory metrics within the instance. But for complete instance control, you will need memory usage statistics for any instance, as well as its CPU usage and network I / O operations. But we can use the cloudwatch custom metrics feature to send any application-level data to Cloudwatch and track it using amazon tools. You can follow this blog for more information: http://upaang-saxena.strikingly.com/blog/adding-ec2-memory-metrics-to-aws-cloudwatch

In this case, you can set cron to a 5-minute interval, and all data points can be seen in Cloudwatch.

Answer 2

CloudWatch does not actually provide memory usage metrics for the EC2 instance, you can confirm it here .

As a result, the MemoryUtilization metric you are referring to is obviously a custom metric that is being pushed by something you configured, or some kind of application running on your instance.

As a result, you need to determine what is actually pushing the data for this metric. The data source is clearly pushing the wrong thing or unreliable.

The behavior you see is not a CloudWatch issue.