Without historical baselines, every CPU spike on the city’s GIS servers looks like an emergency. What should ops establish to make metrics and alerting meaningful?
Select an answer to reveal the explanation.
Short Explanation
Baselines are knowing what “normal rush hour” looks like on the freeway—without them every bump feels like a crash. Once GIS CPU has a normal range, real emergencies stand out from routine peaks. Raw thresholds with no history turn ops into permanent crisis mode.
Full Explanation
Establishing performance baselines so spikes can be judged against normal patterns rather than raw thresholds alone makes metrics and alerting meaningful for city GIS servers. Deleting historical metric data so dashboards always look new destroys the baseline needed for judgment. Setting every alert threshold to zero so any nonzero CPU pages immediately creates endless false emergencies. Ignoring CPU entirely and alerting only on disk free space misses a primary GIS pressure signal. Exam caveat: baselines contextualize anomalies; absolute zero-threshold alerting is a common trap. Operational check: collect seasonal GIS baselines, set threshold bands relative to norms, and revisit after major imagery jobs change load shape. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate. Confirm monitoring, access reviews, and backup coverage still align with the selected approach before closing the civic hypercare period.