A platform team needs to programmatically retrieve all currently open Instana alert events and feed them into a custom executive reporting dashboard that refreshes hourly. Which approach correctly uses Instana's APIs to satisfy this requirement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The Instana backend REST API's /api/events endpoint returns open and historical alert events in JSON format. Clients authenticate using the header 'Authorization: apiToken <token>' with a token generated in Instana's API Tokens settings. This pull-based approach allows external systems to query current event state on demand, suitable for dashboard refresh cycles independent of Instana's push-based webhook mechanisms.
Full explanation below image
Full Explanation
The Instana backend REST API's /api/events endpoint returns open and historical alert events in JSON format. Clients authenticate using the header 'Authorization: apiToken <token>' with a token generated in Instana's API Tokens settings. This pull-based approach allows external systems to query current event state on demand, suitable for dashboard refresh cycles independent of Instana's push-based webhook mechanisms. The correct answer is 'Send a GET request to the Instana backend REST API at /api/events with the API token in the Authorization header and parse the JSON response'. The incorrect options — "Use the Instana agent's local REST API on port 42699 to query global events across all monitored hosts", "Configure an Instana webhook Alert Channel that pushes all new events to the reporting dashboard's ingest endpoint in real time", "Use Instana's Prometheus metrics endpoint to scrape event counts and reconstruct event details in the reporting layer" — are wrong because they do not align with IBM Instana's architecture or recommended practices for this scenario. Understanding this concept is essential for the Domain 4: Integration domain of the IBM Instana Observability certification.