An ECS service on EC2 sends container logs with the awslogs driver, and those logs are arriving. Memory used on the container instances does not appear in CloudWatch. No agent is installed on the instances. What should be added for the memory metric?
Select an answer to reveal the explanation.
Short Explanation
The log driver is a courier for what the container prints. It does not weigh the host's memory. You install the CloudWatch agent on the container instances for that metric, and detailed monitoring will not grow a memory series out of the hypervisor counters.
Full Explanation
The awslogs driver ships the container's stdout and stderr to a log group. Host memory is a guest metric, and on EC2 it is published by the CloudWatch agent, which is not installed here. Installing and configuring that agent on the container instances fills the gap without changing the log driver that already works. CloudTrail does not record operating-system memory. Detailed monitoring increases the frequency of existing EC2 metrics and does not add memory. Caveat: the instance profile needs permission to publish metrics, or the agent will log a deny and the graph will stay empty. Operational check: after the agent starts on one container instance, confirm a memory datapoint for that instance, then roll the agent out to the rest. Memory is collected in the agent's metrics section and published on the period you set. The awslogs driver can stay as it is; it and the agent do different jobs on the same instance. Roll the agent with a State Manager association or the user data of the capacity provider's launch template so new container instances do not come up without it.