Monitoring, Operations, and Troubleshooting
Observability stack
CloudMonitor collects metrics (CPU, memory with agent, disk, network), sets alarms, and drives notifications and Auto Scaling. ActionTrail records API-level audit events. Log Service (SLS) centralizes logs and supports querying and alerting. Application Real-Time Monitoring Service (ARMS) covers APM and tracing. Together: metrics, logs, traces, and audit.
Troubleshooting method
Work layer by layer: is the instance running? Is the security group allowing the port? Is the OS service listening? Is the SLB health check passing? Is DNS resolving? Is the route table sending traffic the right way? This ordered approach resolves most scenario questions.
Common failure signatures
- SLB reports all backends unhealthy - health check port/path wrong, or security group blocking the health-check source.
- Instance unreachable on a port - security group missing the rule, or the service bound to localhost only.
- Intermittent timeouts - undersized instance, connection limits, or a single-zone bottleneck.
- Metric shows high CPU but low app throughput - I/O wait or a noisy-neighbor-style disk bottleneck; check disk metrics.
Traps
- Assuming CloudMonitor captures memory by default - it needs the monitoring agent installed.
- Looking only at the application when the fault is network or security-group related.
- Forgetting that alarms need notification contacts/groups configured to actually reach anyone.
- Ignoring ActionTrail when investigating "who changed this configuration."
Rule of thumb
When something breaks, verify in order: resource state → network path (security group, route, SLB health) → OS/service → application logs → metrics trend. Use ActionTrail for change-related incidents and SLS for correlated log analysis.
Worked example
Users report 502s from an SLB. Check backend health: one instance is unhealthy because the health-check path returns 404 after a deploy. Fix the path or the app route; the SLB resumes traffic. ActionTrail confirms the deploy timing.