Write a Tiny Linux Resource Reporter That Flags Usage Spikes

You're given shell access to a Linux virtual machine inside an online coding environment. Rather than an algorithms question, the task is hands-on: write a small agent that reads the box's own resource usage and reports it to a collector server the interviewer has already stood up.

Part 1 — Read CPU, memory and disk usage

Write code that reports:

• Current CPU utilization as a percentage, measured over a short interval (not a cumulative total since boot).
• Current memory utilization as a percentage of total RAM.
• Current disk utilization as a percentage of the root filesystem.

You may use any language available on the VM; Python with only the standard library is assumed below, but the ideas transfer directly.

Part 2 — Report it to a collector

Pack the three readings into a JSON document and send it as the body of an HTTP POST to an endpoint URL supplied by the interviewer. If the very first request you send comes back 403 Forbidden, diagnose why before anything else, out loud, with the interviewer.

Part 3 — Flag a sustained spike

Add a check that runs before each report is sent: only flag a resource spike when a rolling window of the last N readings averages above a given threshold — a single noisy sample above the threshold should not trigger a flag on its own.

class SpikeDetector:
    def __init__(self, window_size: int, threshold_pct: float): ...
    def add_reading(self, cpu_pct: float, mem_pct: float, disk_pct: float) -> bool:
        """Record one reading; return True iff the rolling average of the
        worst of the three metrics now exceeds threshold_pct."""

Constraints and Clarifications

• Assume Linux unless told otherwise; the VM has no special permissions beyond a normal user.
• The collector's expected JSON field names, authentication (if any), and exact units are not given up front — state your assumptions clearly, such as percentages as floats and a Unix timestamp in seconds.
• window_size and threshold_pct are provided by the caller; readings arrive one at a time, in order, at whatever cadence the caller chooses to call add_reading.

Clarifying Questions

• What JSON shape and field names does the collector expect, and does it require a hostname or an auth header?
• For CPU, is overall utilization across all cores enough, or is per-core detail wanted?
• For disk, is the root filesystem sufficient, or should every mounted filesystem be reported?
• Is this a one-shot report, or should it loop and report periodically — and at what interval?

Part 1 — Collecting the metrics

Common Linux command-line tools for CPU and memory don't have special access — they parse plain-text files the kernel exposes. Find those files directly instead of shelling out to, and re-parsing, a formatted tool's output.

CPU time is reported as a running total since boot, in several categories. Getting a percentage "right now" means sampling that total twice, a short interval apart, and looking at the difference.

What This Part Should Cover

• The exact source file or syscall for each metric, and its units before conversion to a percentage
• CPU measured as a short-interval delta, not a snapshot of the cumulative counters
• A reasonable choice of "memory used" that accounts for reclaimable cache, not just free vs. total

Part 3 — The rolling-window check

The check needs the last N readings, not just the latest one. A bounded-size queue that evicts its oldest element as new ones arrive is the natural fit.

What This Part Should Cover

• A data structure that holds exactly the last N readings without manual bookkeeping
• Returning False until the window actually has N readings, rather than a false positive on a short history
• Which of the three metrics (or what combination of them) feeds the rolling average