📊 Day 23/30: Monitoring & Observability on AWS — How to Detect and Troubleshoot Cloud Application Issues? ☁️
📊 Welcome to Day 23 of the 30-Day Cloud Computing & Cloud Architecture Challenge! What happens when your cloud application becomes slow, starts returning errors, or stops responding? How do cloud engineers find the problem and keep applications running smoothly? In this article, we'll explore Monitoring & Observability on AWS using our college examination portal as a real-world example. 🚀 Keep learning, keep building, and continue your cloud journey! #AWS #CloudComputing #Monitoring#30DayChallenge
Series: Cloud Computing (24 articles)
- …
- 24📊 Day 23/30: Monitoring & Observability on AWS — How to Detect and Troubleshoot Cloud Application Issues? ☁️ This article
📊 Day 23/30: Monitoring & Observability on AWS — How Do We Know When Our Cloud Application Is in Trouble? ☁️
Imagine your college examination portal is now live.
Thousands of students use it to log in, download hall tickets, check exam schedules, and view results.
Your development team has successfully deployed the application using a CI/CD pipeline.
Everything seems perfect.
But one morning, students start complaining.
Some students cannot log in. The results page takes 10 seconds to load. A few requests fail, while others work normally.
The application is still running, but something is clearly wrong.
Now imagine you're the cloud engineer responsible for this application.
How will you find out what is happening?
How will you know whether the problem is caused by the application, the database, the network, or increased traffic?
And how can you detect these problems before thousands of students complain?
This is where Monitoring and Observability become essential.
Welcome to Day 23 of our 30-Day Cloud Computing & Cloud Architecture Challenge! 🚀
Today, we'll explore how cloud engineers monitor applications, detect failures, investigate problems, and maintain reliable cloud systems using AWS.
1. What Is Monitoring?
Monitoring means collecting and checking information about a system to understand its health and performance.
Think of monitoring as checking your own health.
You might measure your temperature, heart rate, and blood pressure to understand whether something needs attention.
Similarly, cloud engineers monitor application metrics such as:
- CPU utilization
- Memory usage
- Request count
- Response time
- Error rate
- Database connections
- Network traffic
Let's return to our examination portal.
Suppose the portal normally responds in less than one second. Suddenly, the average response time increases to eight seconds.
Monitoring helps the team notice this change.
The engineer can investigate the cause before the problem becomes worse.
In simple words: Monitoring helps you understand whether your application is working as expected.
2. What Is Observability?
Monitoring tells you when something appears wrong. Observability helps you investigate why it might be wrong.
Imagine the examination portal becomes slow.
A monitoring dashboard shows that response times have increased.
But this information alone doesn't tell you the exact reason.
The cause could be:
- A slow database query
- An application error
- A dependency that is not responding
- Increased traffic
- A network problem
To investigate, you need more detailed information about what happened inside the system.
This is where observability helps.
Observability commonly uses three important types of telemetry:
- Metrics — Numerical measurements of system behaviour.
- Logs — Records of events that happened.
- Traces — Information showing how a request travels through different services.
Together, these signals help engineers understand system behaviour and investigate problems.
Monitoring vs Observability
| Monitoring | Observability |
|---|---|
| Checks system health and performance | Helps investigate internal system behaviour |
| Uses dashboards, metrics, and alerts | Uses metrics, logs, traces, and other diagnostic data |
| Helps identify that something is wrong | Helps explore why it may be wrong |
| Example: Error rate increased | Example: Trace and logs reveal a failing database call |
They are closely related. Observability supports monitoring and deeper troubleshooting rather than replacing monitoring.
3. Understanding Metrics
Metrics are numerical measurements collected over time.
For our examination portal, important metrics include:
CPU Utilization
CPU utilization tells us how much processing capacity is being used.
If the application's CPU stays near 100% for a sustained period, the server may struggle to handle requests.
However, high CPU usage doesn't always mean something is wrong. The team must understand the application's normal behaviour and workload.
Memory Usage
Memory usage shows how much memory an application or server is consuming.
High or continuously increasing memory usage can indicate that the application needs more capacity or may have a memory leak.
Response Time
Response time measures how long an application takes to respond to a request.
For example:
- 200 milliseconds: 0.2 seconds
- 1,000 milliseconds: 1 second
- 5,000 milliseconds: 5 seconds
If students have to wait several seconds to view their results, the team should investigate the delay.
Error Rate
The error rate shows how frequently requests fail.
For example, if 100 requests are made and 5 fail, the error rate is 5%.
A sudden increase in errors may indicate an application bug, a failing dependency, a configuration issue, or insufficient capacity.
Request Count
Request count shows how many requests an application receives during a period.
Imagine 500 students normally use the portal at the same time, but 10,000 students open it just before an examination.
The increased traffic may require additional application capacity.
Monitoring these metrics helps engineers understand the application's workload and performance.
4. What Are Logs?
Logs are records of events that happen inside an application or system.
Imagine a student tries to download a hall ticket but receives an error.
A log might record information such as:
1
2
3
4
5
Timestamp: 10:15:22
Service: HallTicketService
Event: Hall ticket request failed
Error: Database query timed out
Request ID: req-1042This is an illustrative example, not an actual AWS log.
The log gives the engineer a starting point for investigation.
They can search for related events, check the database, and determine whether the failure affected other students.
Applications should avoid writing passwords, access tokens, or unnecessary sensitive student information into logs.
Good logging provides useful diagnostic information while protecting privacy.
5. What Are Distributed Traces?
Modern cloud applications often use multiple services to handle a single request.
For example, when Rahul checks his examination results, the request might travel through:
1
2
3
4
5
6
7
8
9
10
11
12
13
Student Browser
|
v
API Gateway
|
v
Application Service
|
v
Database
|
v
Response to StudentIf the results page is slow, which component is causing the delay?
A distributed trace can show how long each part of the request takes, provided the application and services are instrumented appropriately.
For example:
1
2
3
4
5
6
Total Request Time: 4.8 seconds
API Request: 0.1 seconds
Application Logic: 0.2 seconds
Database Query: 4.3 seconds
Response Processing: 0.2 secondsThis example suggests that the database query is the main source of delay.
Instead of guessing, the engineer now has a useful direction for investigation.
Distributed tracing becomes especially helpful when applications use multiple services, APIs, and databases.
6. Which AWS Services Help With Monitoring?
AWS provides several services to help engineers monitor and investigate cloud applications.
Amazon CloudWatch
Amazon CloudWatch collects and displays monitoring information such as metrics and logs from supported AWS services and applications.
It can help engineers:
- View resource metrics
- Collect application logs
- Create dashboards
- Set alarms
- Monitor application health
For example, an engineer can use CloudWatch to monitor the CPU utilization of an Amazon EC2 instance.
CloudWatch Alarms
CloudWatch alarms can evaluate metrics against configured thresholds or conditions and initiate configured actions.
For example, you might configure an alarm when CPU utilization remains above 80% for a specified period.
The alarm can notify the team or trigger a suitable action.
The threshold must fit the workload. A brief CPU spike does not always require intervention.
AWS X-Ray
AWS X-Ray helps developers analyse requests as they travel through supported application components and services.
It can help identify slow operations, errors, and performance bottlenecks.
This is useful when the examination portal depends on several backend services.
AWS CloudTrail
CloudTrail records account activity and API events for supported AWS operations.
For example, if a cloud resource's configuration changes unexpectedly, CloudTrail can help investigate which identity performed the action and when.
CloudTrail serves a different purpose from application performance monitoring: it focuses on AWS account activity and auditing.
Amazon Managed Service for Prometheus
This service supports Prometheus-compatible metrics monitoring for suitable workloads.
It can be useful when teams use Prometheus to monitor containerized applications and other supported environments.
Amazon Managed Grafana
Amazon Managed Grafana helps teams create dashboards and visualizations using supported data sources.
It can be useful when engineers want to bring different monitoring data sources into a common view.
Remember: You don't need every service in every architecture. Choose tools according to the application, monitoring needs, operational skills, and budget.
7. What Are Alerts and Why Do We Need Them?
Imagine the examination portal starts returning errors at 2 AM.
If nobody is watching the dashboard, the issue may remain unnoticed until students start using the portal in the morning.
Alerts help notify the right people when configured conditions indicate a problem.
For example, a team might create alerts for:
- A high application error rate
- Sustained high CPU utilization
- Unusually slow response times
- A database reaching a connection limit
- Failed health checks
A simplified alert workflow looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Application Produces Metrics
|
v
CloudWatch
|
v
Alarm Condition
|
v
Notification or Action
|
v
Engineer Investigates
|
v
Fix and VerifyDepending on the configuration, notifications can be sent through Amazon SNS or other integrated systems.
Good alerts should be actionable. Too many unnecessary alerts can overwhelm a team and cause important incidents to be missed.
8. What Is an SLA, SLI, and SLO?
Cloud engineers also need to understand how reliability is measured.
These three terms are related but different.
SLI — Service Level Indicator
An SLI is a measurement of service performance or reliability.
Examples include:
- Request success rate
- Response latency
- Service availability
SLO — Service Level Objective
An SLO is a target for an SLI over a defined period.
For example, a team might aim for 99.9% successful requests over a rolling 30-day period.
This is an example target, not a guarantee that the service will achieve it.
SLA — Service Level Agreement
An SLA is a formal agreement that defines service commitments and may include remedies if those commitments are not met.
For example, a cloud provider's SLA may describe availability commitments and the conditions under which service credits apply.
Easy way to remember:
- SLI = What you measure
- SLO = What you aim for
- SLA = What is formally agreed
These concepts help teams move beyond simply saying, "The application seems to be working."
9. How Monitoring Helps During an Incident
Let's imagine the examination portal becomes slow just before an important exam.
Here is how a cloud engineer might investigate.
Step 1: Detect the problem
A CloudWatch alarm indicates that response times or error rates have crossed a configured threshold.
Step 2: Check the dashboard
The engineer reviews application metrics, CPU utilization, traffic levels, and database performance.
Step 3: Investigate logs
The engineer searches the relevant application logs for errors, timeouts, and failed requests.
Step 4: Follow the request
If distributed tracing is available, the engineer checks which component is taking the longest or returning errors.
Step 5: Take action
Depending on the cause, the team might optimize a database query, fix a bug, increase capacity, or correct a configuration.
Step 6: Verify the recovery
The team checks whether response times and error rates return to acceptable levels.
Step 7: Learn from the incident
The team documents the cause, identifies ways to prevent a repeat, and improves alerts or tests where needed.
This process helps turn a confusing failure into a structured investigation.
10. Monitoring and Observability in a Real AWS Architecture
Let's connect today's concepts with the examination portal we've been building throughout this challenge.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Students
|
v
CloudFront
|
v
API Gateway
|
v
Application Service
|
v
Database
Monitoring and Investigation
----------------------------
Amazon CloudWatch
CloudWatch Logs and Alarms
AWS X-Ray (where applicable)
AWS CloudTrail (account activity)The application and its supporting services produce information that engineers can use to understand health, performance, and failures.
The exact setup depends on which services the application uses, how telemetry is collected, and what the team needs to monitor.
Monitoring should be designed from the beginning, not added only after the first major failure.
11. Mini Project: Monitor Your College Examination Portal
Now it's your turn to think like a cloud engineer.
Imagine your college examination portal is running on AWS.
Design a basic monitoring plan with the following requirements:
- Track application errors and response times.
- Monitor CPU utilization for application servers, if using EC2.
- Collect useful application logs.
- Configure an alert for a sustained increase in errors.
- Investigate slow requests using logs or distributed traces.
- Monitor database health using the metrics available for your chosen database.
- Record AWS account activity that may be important for auditing.
- Create a dashboard that helps the team understand application health.
Try using Amazon CloudWatch for metrics, logs, dashboards, and alarms.
If your application uses supported distributed tracing integrations, explore AWS X-Ray as well.
Challenge: Imagine the results page suddenly takes five seconds to load. Write down three possible causes and identify which metric, log, or trace could help you investigate each one.
12. Quick Revision Questions
Q1. What is monitoring?
Monitoring means collecting and checking information about a system's health and performance.
Q2. What is observability?
Observability helps engineers investigate internal system behaviour using telemetry such as metrics, logs, and traces.
Q3. What are metrics?
Metrics are numerical measurements such as CPU utilization, response time, and error rate.
Q4. What are logs?
Logs are records of events that occur in an application or system.
Q5. What are distributed traces?
Distributed traces show how requests travel through instrumented services and how much time different operations take.
Q6. What is Amazon CloudWatch used for?
It helps collect and view metrics and logs, build dashboards, and configure alarms.
Q7. What is AWS CloudTrail used for?
It records AWS account activity and API events for auditing and investigation.
Q8. What is the difference between an SLI and an SLO?
An SLI is a measurement, while an SLO is a target for that measurement.
Final Thoughts
Building a cloud application is only one part of a cloud engineer's job.
You must also understand whether the application is healthy, how users experience it, and what happens when something fails.
Monitoring helps you detect problems. Logs help you investigate events. Distributed traces help you follow requests across services. Alerts help notify the team when action may be needed.
With tools such as Amazon CloudWatch, AWS X-Ray, and AWS CloudTrail, engineers can build a clearer picture of application performance and cloud activity.
The big lesson: You cannot reliably manage what you cannot observe.
Tomorrow, in Day 24, we'll explore Cloud Cost Optimization — How Can We Reduce AWS Costs Without Sacrificing Performance? 💰☁️
Series: Cloud Computing (24 articles)
- …
- 24📊 Day 23/30: Monitoring & Observability on AWS — How to Detect and Troubleshoot Cloud Application Issues? ☁️ This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article