A cloud operations team needs to implement a monitoring solution for a microservices architecture. The solution must provide centralized logging, metrics, and alerting, and must be able to correlate data from multiple services. Which THREE of the following components should the team include?
Trap 1: A security information and event management (SIEM) system.
A SIEM correlates security events and generates threat alerts, but it does not aggregate application logs or service metrics for operational monitoring across microservices. It is tempting because SIEM genuinely centralises and correlates data, and would be correct if the requirement were security incident detection rather than operational observability.
Trap 2: An application performance monitoring (APM) tool.
APM tools trace application transactions and latency within instrumented services, but they do not provide the centralised log aggregation or cross-service log correlation the solution demands. They are tempting because APM genuinely covers metrics and alerting for service performance, and would be correct if distributed tracing alone were required.
- A
A security information and event management (SIEM) system.
Why it fails: A SIEM correlates security events and generates threat alerts, but it does not aggregate application logs or service metrics for operational monitoring across microservices. It is tempting because SIEM genuinely centralises and correlates data, and would be correct if the requirement were security incident detection rather than operational observability.
- B
A centralized logging system (e.g., ELK stack).
Centralised logging aggregates log streams from every microservice into one searchable store, satisfying the stem's centralised logging requirement. Without it, correlating events across services is impossible, since each container's logs remain isolated on its own host and are lost when instances are recycled.
- C
A correlation engine and alerting system (e.g., event correlation).
The correlation engine consumes events from logging and metrics pipelines, applying rules to link related signals across services and trigger alerts. This directly satisfies the stem's alerting and multi-service correlation requirements, which raw log storage and dashboards alone cannot deliver.
- D
A metrics collection agent and dashboard (e.g., Prometheus+Grafana).
Metrics collection agents scrape time-series data such as request rates and latency from each service, and the dashboard visualises them centrally. This satisfies the stem's metrics requirement, complementing logs by exposing quantitative trends needed to correlate behaviour across microservices.
- E
An application performance monitoring (APM) tool.
Why it fails: APM tools trace application transactions and latency within instrumented services, but they do not provide the centralised log aggregation or cross-service log correlation the solution demands. They are tempting because APM genuinely covers metrics and alerting for service performance, and would be correct if distributed tracing alone were required.