A site reliability engineer is automating a weekly capacity review for a retail SD-WAN overlay. The job must land in one statistics request per run, cover one fixed past window whose bounds are already in epoch milliseconds, and return rows only for the three branch devices under review. Which query structure should the script send to Manager?
Select an answer to reveal the explanation.
Short Explanation
You’ll want one AND query, like a single checklist, combining the fixed entry_time window with a device-name rule. Make that device rule select all three branches together, rather than sending a separate rule for each one.
Full Explanation
The correct structure combines the fixed entry_time bounds and the three-device selector with AND in a single statistics request. The time rule limits results to the specified past window, while the device rule limits them to the branches under review; both conditions must hold for a row to be returned. Replacing AND with OR is a plausible way to combine filters, but it returns rows matching either condition: that can include records from other devices within the window and records for the selected branches outside it. A rolling window of equal duration is also a common monitoring pattern, but its endpoints move with the run time, so it does not honor bounds already supplied in epoch milliseconds. Issuing one request per branch and merging results preserves the intended time and device scope, but violates the requirement for one statistics request per run. Exam caveat: confirm the Manager query language’s Boolean grouping and timestamp units; an entry_time range may require its own correctly paired lower- and upper-bound clauses. Practical check: inspect the serialized request to verify one request contains the exact epoch-millisecond bounds and all three device names under AND, then confirm a test response has no out-of-window rows or unselected device IDs.