Collect CPU, Memory and Disk Metrics, POST Them as JSON, and Add a Threshold Check

You are given a virtual machine inside an online coding environment. Instead of an algorithm puzzle, the task is practical: write a program by hand that reads the machine's CPU, memory and disk information, packs it into a JSON document, and sends it in an HTTP POST request to a server that the interviewer set up for the exercise. Once that works, the interviewer extends it: before a report is sent, check the readings against a given threshold. The interviewer framed this follow-up as similar to a simple sliding-window problem. ### Constraints and Clarifications - Use any language available on the VM. Assume it runs Linux unless the interviewer says otherwise. - The endpoint URL comes from the interviewer. The JSON field names, the units, any authentication the server requires, and the exact meaning of "exceeds the threshold" are not given; ask for them or state your assumptions. ### Clarifying Questions - What JSON shape does the server expect: field names, units (percent, bytes, kilobytes), and whether to include a host name and a timestamp? - Which CPU figure is wanted: overall utilization over a short interval, per-core utilization, or the load average? - For disk, is it the root filesystem only or every mounted filesystem, and is disk space enough or is I/O activity wanted too? - May I use third-party packages such as `psutil` or `requests`, or only the standard library and the tools already on the VM? - Is this a single report, or a loop that reports periodically, and at what interval? ### Part 1 — Collect CPU, memory and disk information Write code that reads the machine's current CPU usage, memory usage and disk usage, with explicit units. ```hint Where the kernel keeps the numbers On Linux, the command-line tools that show CPU and memory usage read plain-text files from a pseudo-filesystem. Find out what those tools read, instead of parsing their formatted output. ``` ```hint Counters are not rates CPU time is reported as totals accumulated since boot. Decide what you need in order to turn totals into usage right now. ``` #### What This Part Should Cover - A correct source for each metric, and its units - CPU utilization measured over an interval rather than taken from cumulative counters - A memory figure that reflects what applications can actually still use - Disk space for the filesystems that matter, and what changes inside a container ### Part 2 — Send the readings as JSON in a POST request Serialize the readings into a JSON body and POST it to the interviewer's server. Then suppose every request comes back with HTTP 403 Forbidden: how do you find out why, and what do you change? ```hint More than a status code A rejected request still comes back with headers and usually a body. Decide what you would look at before touching your code. ``` ```hint Read the code precisely Compare what 403 claims about a request with what 400, 401 and 404 would claim, and which part of your request each one points at. ``` #### Clarifying Questions for this Part - Does the server expect an authentication header, such as an API key or a bearer token, or any other specific header? - Is the endpoint HTTP or HTTPS, and is the path exactly as given? - Does the VM reach the server directly, or through a proxy? #### What This Part Should Cover - A valid JSON body sent with the right content type, a timeout, and handling of non-2xx responses - A methodical diagnosis of the 403 that starts from the response itself rather than guesswork - Separating problems in the request from authentication, authorization and network-path problems - Reproducing the request outside the program to isolate the fault ### Part 3 — Threshold check before sending Before each report is sent, compare the readings against a given threshold. Define precisely what "exceeds the threshold" means, then implement the check (or walk through it verbally if time is short) and show how it fits into the reporting loop. ```hint One spike is not a trend Think about what a window over recent readings lets you conclude that a single reading cannot, and what that implies for the breach rule. ``` ```hint Update, do not recompute When a new reading enters the window and the oldest one leaves, decide what you can adjust incrementally instead of rescanning the whole window. ``` #### Clarifying Questions for this Part - Is the threshold applied to the latest reading, to the average over the window, or to how many readings in the window are above it? - Is the window a fixed number of samples or a span of time? - Does a breach add an alert to the report, trigger a separate request, or decide whether a report is sent at all? - Is there one threshold per metric, or one value shared by all three? #### What This Part Should Cover - An explicit, agreed definition of a breach - A window structure with constant work per sample and bounded memory - Behavior before the window has filled, and while a breach persists - How the check plugs into sampling and sending ### What a Strong Answer Covers - A working end-to-end program: correct readings, a valid JSON request, and a handled response - Correct units and an interval-based CPU measurement - Robustness: request timeouts, no crash when a metric source is missing, and no retry storm on errors that will not go away - Systematic debugging of the 403 instead of trial and error - A sliding-window check whose semantics are stated and whose cost per sample is constant ### Follow-up Questions - How would you run this reporter on thousands of machines without overwhelming the collecting server? - If the server is unreachable for several minutes, what happens to the readings taken meanwhile? - If the rule became "a high percentile of CPU over a time window exceeds the threshold" instead of an average, how would the check change? - How would you test the reporter without a real server or a genuinely loaded machine?