A hotel chain NOC wallboard already polls assurance APIs to fill its tiles, and the NOC has asked not to receive any more email. Which handoff should keep feeding that wallboard?
Select an answer to reveal the explanation.
Short Explanation
The hotel wallboard is a scoreboard that already knows how to fetch the score. You keep feeding it through the API it polls, because the NOC asked not to get more email. A telemetry push it cannot read, a new email threshold, or a ticket per sample adds noise the board was built to avoid.
Full Explanation
The NOC already has a wallboard that polls an API, and the only new constraint is that the desk does not want more email. The handoff that matches both facts is to keep publishing measurements through the API the wallboard already polls. Pushing an OpenTelemetry stream at a board that is not written to consume one adds a protocol the display does not read, so the tiles do not update from that stream. Adding an alert threshold that emails the NOC whenever a tile would change is the mail the desk asked to stop, and a mailbox is not how this wallboard is filled. Opening an ITSM ticket for every sample interval creates a queue of records the board does not poll and buries the NOC in tickets for data it already shows. Exam caveat: an alert threshold is appropriate when a person asked to be notified, not when a display is already polling. Operational check: confirm the wallboard tiles still refresh from the API and that no new mail is generated for the same intervals. If the board goes stale or the inbox fills, the handoff no longer matches the request.