Three pillars (metrics, logs, traces) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the role of metrics in microservices monitoring

Which of the following best describes the primary purpose of metrics in monitoring microservices?

A Metrics offer aggregated numerical data over time to track system performance and health.

B Metrics trace the path of a request through multiple services to identify latency bottlenecks.

C Metrics provide detailed records of individual events and errors for debugging purposes.

D Metrics store raw logs from all microservices for audit and compliance.

💡 Hint

Think about what numbers like CPU usage or request counts represent.

Metrics are aggregated numerical data points collected over time to monitor system health and performance trends.

❓ Architecture

intermediate

Choosing the right pillar for debugging a failed request

You notice a user request failed in your microservices system. Which pillar should you consult first to find detailed information about the error and its context?

A Metrics, because they show aggregated error rates over time.

B Traces, because they provide numerical summaries of system health.

C Logs, because they contain detailed event records and error messages.

D Metrics and traces only, since logs are too large to be useful.

💡 Hint

Consider which pillar records detailed messages about what happened.

Logs contain detailed records of events and errors, making them the best source for debugging specific failures.

❓ scaling

advanced

Scaling trace collection in a high-traffic microservices environment

Your microservices system handles millions of requests per minute. You want to collect traces to understand request flows without overwhelming storage or processing. Which approach is best?

A Only collect metrics and logs, ignoring traces to save resources.

B Collect traces for every request and store all data indefinitely.

C Collect traces only for requests that do not generate logs.

D Sample a small percentage of requests for tracing and keep traces for a limited time.

💡 Hint

Think about balancing data volume and usefulness.

Sampling a small percentage of requests reduces data volume while still providing useful trace insights.

❓ tradeoff

advanced

Tradeoffs between logs and metrics for alerting

When setting up alerts for your microservices, what is a key tradeoff between using logs versus metrics?

A Logs provide fast, aggregated alerts but lack detail; metrics provide detailed alerts but are slow.

B Metrics enable fast, low-overhead alerts but may miss detailed context; logs provide rich detail but are costly to process in real-time.

C Logs and metrics both provide identical alerting capabilities with no tradeoffs.

D Metrics are only useful for debugging, while logs are only useful for performance monitoring.

💡 Hint

Consider speed and detail in alerting.

Metrics allow quick, efficient alerts but lack detailed context; logs provide rich detail but are expensive to analyze in real-time.

❓ estimation

expert

Estimating storage needs for logs, metrics, and traces

Your microservices system generates the following per minute: 10 million requests, 100 metrics per service per minute (50 services), and 1 log entry per request. Estimate the relative daily storage needed for logs, metrics, and traces assuming traces are collected for 1% of requests and each trace is 10 times the size of a log entry.

A Logs: 14 TB, Metrics: 720 MB, Traces: 1.4 TB

B Logs: 1.4 TB, Metrics: 720 GB, Traces: 14 TB

C Logs: 14 GB, Metrics: 720 MB, Traces: 140 GB

D Logs: 140 TB, Metrics: 7.2 GB, Traces: 14 TB

💡 Hint

Calculate logs as requests × log size × minutes per day; metrics as metrics × services × minutes per day; traces as 1% of requests × 10 × log size × minutes per day.

Logs dominate storage due to volume; metrics are small; traces are fewer but larger per item.