How a municipal government cloud project met MLPS log-retention rules with hot and cold storage, built four-field audit search, routed three-tier alerts to on-call staff, and rehearsed failover — without drowning anyone in noise.
Government cloud systems share two traits: availability is a hard target, and log retention plus auditing are red lines. An observability platform here is not a nice-to-have — it must simultaneously satisfy "find problems fast" and "produce something when the auditors come." This article describes how we delivered both on a municipal government cloud project.
MLPS 2.0 requires log retention of at least six months, and systems handling important data may need longer. The first step is to size the volume: a government system with a million calls a day, at roughly 500 bytes per record, produces about 500 MB a day — around 90 GB over six months, doubled after compression and replicas.
We split logs into hot and cold tiers. The last 30 days sit in hot storage for fast search; everything older moves to cold storage (object storage or archive disks) and is kept but rarely queried. "Retention" required by compliance is not the same as "instant search" — moving cold data somewhere cheap cuts cost by more than half, and we handle integrity and tamper-evidence checks at the same time. Cold data is hashed per file block and archived, so during an audit we can prove "this batch of logs has not been modified since it was written."
The thing government scenarios fear most is not an outage but "we can't explain what happened afterwards." So auditing focuses on two kinds of operations: administrator and operator actions (login, config changes, data deletion), and key business-data changes.
The platform collects, stores, and authorizes operational logs separately from business logs. Audit logs are append-only and cannot be deleted, and the auditor role gets read-only access. During an inspection, staff search by four fields — person, time, action, object — and produce a report in minutes instead of digging for half a day. Before every review or MLPS re-check, we export the relevant records by those four fields in advance, so on the day of the review we hand over materials instead of scrambling through the database.
Government cloud alerting tends to fall into one of two extremes: an alert storm that numbs the on-call staff, or thresholds set so loose that nobody knows when something breaks. We use three tiers: strict thresholds on the availability and latency of core business interfaces, aggregate alerts plus silence windows for infrastructure, and record-only (no paging) for non-critical metrics.
On-call routing follows impact: anything affecting public services reaches the government app and enterprise WeChat group within a minute; internal systems go through email and SMS. A weekly alert report tracks false-alarm rate and mean response time, which pushes the alert rules to keep converging. Cross-department coordination is agreed in advance too: which interface belongs to which bureau, and who is first in line when it breaks, all written into the on-call handbook instead of figured out after the fact.
Government cloud demands high availability, so monitoring alone is not enough. We deployed the key systems across two centers, and the observability platform itself fails over with the business; if the primary center goes down, traffic moves to the backup within an accepted window, with RPO and RTO both load-tested in advance.
Every month we run a failure drill: from alert firing, to locating the issue, to failover and recovery, walking the full path and recording the time it took. The drill is not theater — it verifies the "alert to root cause" path actually works, and it forces us to fix the outdated contacts in the on-call handbook.
Observability in government cloud is really about "accountability traceable, state perceivable." Doing those two things well beats piling up flashy features.