6.1System monitoring and job management

System operation begins with "catching anomalies before they become an SLA breach." A service manager must design which items to monitor at which thresholds so that problems are noticed while still just a sign, build a schedule that runs many jobs—such as an overnight batch—within the time window while preserving their dependencies, and decide in advance the handling that minimizes service impact when a job ends abnormally (abort, rerun, skip). Monitor too finely and an alert flood buries the real anomaly; too coarsely and it is too late—designing this balance is the core of the practice.

6.1.1Monitoring items, thresholds, and alerts

• Monitoring items are indicators of service health. Distinguish resource-level items (CPU utilization, memory, free disk, network bandwidth) from user-facing service-level items (response time, transaction success rate, error rate). If the SLA is stated in terms of "response time," you must monitor the response time the user actually experiences, not just CPU utilization, or you cannot directly detect the SLA breach.
• Thresholds are the boundary values at which an alert fires. Rather than a single threshold, the standard practice is a two-stage split into warning and critical. Warning lets you begin remediation with margin and prevent the SLA breach before reaching critical. Setting thresholds too tight causes false positives and frequent alerts, so operators become desensitized and miss the real ones (alert fatigue).