An API implementation is deployed on a single worker on CloudHub and invoked by external API clients (outside of CloudHub).
How can an alert be set up that is guaranteed to trigger AS SOON AS that API implementation stops responding to API invocations?
To set up an alert that is guaranteed to trigger as soon as the API implementation stops responding to API invocations, the best option is to configure a 'worker not responding' alert in Anypoint Runtime Manager. This solution provides immediate monitoring and alerting of the worker's status, ensuring timely detection of any unresponsiveness. Other options either require additional implementation effort, like external health checks, or may not be as reliable or immediate in detecting the issue.
B. Configure a ג€worker not respondingג€ alert in Anypoint Runtime Manager.
B. Configure a "worker not responding" alert in Anypoint Runtime Manager.
Answer: B
Out of all options, it should be B.
Cannot be D because not receiving any requests for certain time period does not mean API is not responding. Worker not responding alert for cloudhub is a definitive way of generating an alert. If Cloudhub workder is not responding, API on it won't be responding either.
Should be A (implemented using Functional Monitor > Schedule > Advanced > Cron) B requires min. 90s: "Mule 4.x CloudHub uses the Mule Agent health check endpoint to determine the readiness of a deployment. This monitoring method provides a thorough check to ensure that the application is deployed and applies gateway policies. Every 30 seconds, CloudHub sends an HTTP GET request to the ping flow. If the application is running normally, the ping flow sends a response. If CloudHub receives no response from three consecutive pings, the logs display a warning and a full thread dump. CloudHub triggers a notification to the console to alert you that a worker for an application stopped responding. If you configure email alerts, the unresponsive worker also triggers an email alert based on the Worker Not Responding event."
it says "from outside the Anypoint Platform" so Functional monitor is not an option here.
The correct answer is B. Configure a "worker not responding" alert in Anypoint Runtime Manager. This option allows you to set up an alert that will trigger as soon as the API implementation stops responding to API invocations. Anypoint Runtime Manager constantly monitors the worker and can detect when it becomes unresponsive. This ensures that you are alerted immediately and can take necessary actions to resolve the issue. Option A is not recommended as it requires additional implementation within the API and may not be reliable. Option C requires handling exceptions within the calling API client, which may not be practical or feasible in all scenarios. Option D may not be as effective as it only triggers an alert after a specified time period, which may be too late in some cases.
This one is tricky. Either A and B are valid but the question is for an alert to trigger AS SOON AS that API implementation stops responding. Option B, if we focus on the API implementation part of the question, it's more about API's responsiveness than worker's health. So B might not trigger immediately upon the API becoming unresponsive. Option A, it's a direct method to monitor the API's health but it requires external infrastructure or tooling to perform the health checks since it says invoke the healthcheck from outside the Anypoint Platform. I would go for A.
API being invoked by external client. Work stop responding is not the only possible reason for the API to stop responding. It could be network, DLB, or some other components depending on the setup. The only effective way to monitor the "stop responding" bahaviour is from the outside of the Anypoint platform. So A it is.