Welcome to 'Back to Basics'.
I'm Mai Nishitani, a Solutions Architect from Amazon Web Services.
Today, we're going to be walking through monitoring and observability
for containerized applications,
how do we take those metrics and visualize them as well?
So prior to this role, I used to be a cloud engineer,
and a lot of times I got woken up early in the morning
because there was a code push to production
that broke the infrastructure and our customers couldn't access our web application
running on containers.
So as a cloud engineer, I needed to dive deep into where the problem was,
what the root cause was and how we can prevent it from happening in the future.
We also needed to make sure that our infrastructure was scaling in the back end,
depending on the level of traffic that we were receiving.
So how do we do that?
You want to first baseline your applications on how it operates during non-peak time.
If there are anomalies from the normal pattern,
you can investigate this before a major event, such as a new product launch,
where you're expecting high levels of traffic.
Well, you really don't want to be continuously woken up early in the morning
to investigate what went wrong,
if there are any interruptions to your service.
Let me show you an AWS native architecture pattern
for monitoring your container environment.
Let's start off with the container application running in Amazon ECS.
You can see one of my favorite services,
AWS Distro for Open Telemetry, talking to the application as a typical sidecar architecture pattern.
The application is sending its metrics via the AWS Distro for Open Telemetry collector.
It's also correlating distributed traces and metrics,
then sending it to the Amazon Managed Services for Prometheus.
I like Amazon Managed Services for Prometheus
as it's a Prometheus compatible service that let you monitor
and alert for your containerized applications and infrastructure at scale.
You can also benefit from enhancing your container metrics
via Amazon CloudWatch Container Insights.
In the past with Amazon CloudWatch,
you needed to enable custom monitoring of services and tasks.
With CloudWatch Container Insights,
it provides several key metrics such as your containers' CPU
and memory utilization, and task and service counts out of the box.
Amazon CloudWatch, AWS Distro for Open Telemetry,
and Amazon Managed Services for Prometheus
are all great data sources that collects, monitors,
analyzes, and acts on all the things that are going on in your system.
If you're a cloud engineer, you definitely like to see these metrics
that you're collecting on a dashboard.
So let's talk about how you can take these different sources of data
and visualize them using Amazon Managed Services for Grafana.
Amazon Managed Services for Grafana will help you visualize
all of these data sources into a nice dashboard like this.
You can analyze your metrics, logs, and traces without all the heavy lifting.
There's no need to provision servers,
configure and update software,
and you can also connect your existing identities via AWS Single Sign On.
The top three metrics that you want to look out for in your container applications on ECS
are number one, CPU utilization.
If this metric is nearing capacity in a single service,
you might consider updating that service to include more tasks.
High CPU utilization may indicate CPU intensive workloads.
If this is happening, consider upgrading to a task with a higher vCPU.
Number two, memory utilization.
ECS will terminate any containers that exceed the hard memory limit.
If you set one, you'll want to alert your team when memory utilization approaches
100% so that your containerized application remains available.
Even if you set a soft limit, memory utilization can exceed 100%
without ECS killing containers.
However, it's still good to know whether you're approaching this threshold
as it can help you avoid unexpected out memory errors
for your EC2 Instances or unexpected high Fargate bills.
As with CPU utilization, it's great to know if you are adequately scaling your ECS services.
And lastly, running task count.
You can track the number of tasks
running within a container instance, service, and cluster.
The metric running count can also show whether your services are running tasks
as expected.
When creating or updating a service,
you can specify not only the number of desired tasks,
as in how many tasks the service will attempt to keep running,
but also how many tasks from a previous deployment
you need to keep running while new ones are launched.
In this session, you learned all about an AWS native container monitoring architecture,
and the three major metrics to look out for, for Amazon ECS.
Check out the links below to start building.
Thanks for watching 'Back to Basics'.
See you next time.