City app servers for parking, licensing, and inspections write logs only to local disks, so ops cannot search a single incident across the fleet. What observability capability should the municipality configure first?
Select an answer to reveal the explanation.
Short Explanation
Local logs are like sticky notes stuck inside each office—nobody can see the whole story when something breaks. Log collection pulls those notes into one place so you can search an incident across parking, licensing, and inspections without hopping servers. Fleet-wide troubleshooting starts with getting the logs off the box.
Full Explanation
Deploying log collection that ships logs from distributed hosts into a central searchable store is the first observability capability needed when parking, licensing, and inspections servers write only to local disks and ops cannot search one incident across the fleet. Increasing each VM’s local disk and keeping host-by-host SSH search fails cross-fleet correlation and slows response. Disabling application logging to reduce storage growth fails incident investigation needs. Replacing all logs with a weekly emailed status PDF fails real-time searchable observability. Exam caveat: log collection/aggregation is foundational before fancy analytics—local-only logs are a classic anti-pattern. Operational check: install agents or sidecars, encrypt transport, index key fields, restrict access, and verify a multi-host query during a parking outage game day. 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.