Welcome to Back to Basics! My name is Mai Nishitani, a Solutions Architect from AWS.
In this session you'll learn all about best practice architecture patterns for observability
with Amazon Elastic Kubernetes Service or Amazon EKS which is a container orchestrator.
So why do we need observability for Kubernetes in general? That's to detect, investigate, and remediate
issues for your systems and your customers that use your application on EKS.
But can't you just use the standard monitoring tools that you've used with your virtual machines?
Not so fast, they might not be the right tool for the right job. Especially for distributed architectures like Kubernetes.
With microservices architectures there are multiple pods being created and going away within
minutes. Now due to this ephemeral nature of Kubernetes the usual monitoring tools that we're used to with
virtual machines that have predefined logs and metrics aren't adequate enough in troubleshooting problems.
Now why do we need to troubleshoot problems? That's because your end users won't
be happy if your service isn't up. You might even have service level agreements or SLAs in place to
ensure that your applications are operational under certain conditions. Let's say you're a
platform engineer at a pet food company that runs a web app on a Kubernetes cluster.
The web application is experiencing performance issues and your customers are complaining about it.
To troubleshoot the issue you'll need to use end-to-end observability techniques and tools
from your front end all the way to the back end. This includes logging, metrics, and tracing.
First, you'll need to gather metrics and logs from all the components on the application
including dependencies, the Kubernetes nodes, and the cluster itself. You can use
a tool like AWS Distro for Open Telemetry to centralize and process the logs and metrics.
You can use a tool like Amazon Managed Services for Prometheus to collect the metrics and
Amazon Managed Services for Grafana or Amazon CloudWatch to visualize the metrics. Finally you'll need to
use tracing to understand how the requests are flowing through to the system and identify any
performance bottlenecks. You could use a tool like AWS X-Ray to visualize the trace data.
Using these observability techniques you'll be able to gain an understanding of the state of your system and then
you'll be able to identify the root cause of your performance issues. Once you've identified the
root cause, you'll be able to work on a solution from there. In this case we found out quickly
that the bottleneck was around your Storefront and Datastore apps with the AWS X-Ray trace.
See how you can see the average response latency for each segment.. which allows you to dive deeper
into these apps with CloudWatch metrics and logs for some root cause analysis.
Let's check out the architecture pattern. AWS Distro for Open Telemetry is a tool that allows you to monitor
your application's performance by collecting and analyzing telemetry data such as traces,
metrics, and logs. It works by using receivers to collect the data, processors to perform tasks such
as filtering and transforming the data. Exporters send the data into multiple destinations such
as AWS X-Ray or Amazon Managed Services for Prometheus and Amazon CloudWatch.
So how does that benefit your microservices applications? You will have full control of your observability data
for your microservice on EKS with the flexibility to send data to multiple destinations in parallel.
The best practice to implement this pattern is with Amazon EKS Blueprints. With EKS Blueprints, you
can use it with AWS CDK and Terraform to create consistent environments in configure your EKS
cluster with observability tools across multiple AWS accounts and Regions using infrastructure
as code and automation. Have a look at the resources below to get started with implementing
observability tools for Amazon EKS so you can meet your SLAs and keep your end users happy!
Thank you for watching. Keep on modernizing on containers, see you next time !