Monitoring, Automation and Troubleshooting
Monitoring
CloudMonitor collects metrics (CPU, memory via agent, disk, network), sets alarms, and triggers notifications or Auto Scaling actions. Distinguish basic metrics (hypervisor-level, no agent) from host metrics requiring the CloudMonitor agent (e.g., memory and process counts). Traps: expecting memory metrics without the agent, or setting alarms without notification contacts.
Logging and diagnostics
SLS (Log Service) ingests, indexes, and queries logs; use it for centralized troubleshooting and alerting. ActionTrail answers who changed what and when. For network issues, check security groups, route tables, and NAT/IGW configuration in that order.
Automation
ROS (Resource Orchestration Service) provisions infrastructure as code via templates. OOS (Operation Orchestration Service) automates routine operations like patching and restarts. Function Compute runs event-driven code. Auto Scaling reacts to metric or schedule triggers. Traps: confusing ROS (provisioning) with OOS (operational runbooks), or assuming Auto Scaling fixes application-level errors - it replaces unhealthy instances but won't correct a bad image.
Troubleshooting method
Work from the symptom outward: (1) confirm scope - one instance or all; (2) check recent changes via ActionTrail; (3) verify network path (security group → route → gateway); (4) inspect logs in SLS; (5) review CloudMonitor metrics for resource exhaustion. Change one variable at a time.
Worked rule of thumb
Intermittent 5xx errors behind a load balancer: check health check configuration and backend CloudMonitor metrics first, then correlate with SLS application logs. If instances are being replaced repeatedly, suspect the image or User Data, not the scaler.
Exam framing
Match the tool to the question: metrics → CloudMonitor, logs → SLS, API audit → ActionTrail, provisioning → ROS, runbooks → OOS.