- Mais recentes
- Mais votos
- Mais comentários
I solved my issue by making the following changes to the Heartbeat script. It adds a "requestfailed" handler and waits for networkidle0.
const loadUrl = async function (page, url, takeScreenshot) {
let stepName = null;
let domcontentloaded = false;
page.on('requestfailed', request => {
let requestFailedError = `url: ${request.url()}, errText: ${request.failure().errorText}, method: ${request.method()}`
log.error(requestFailedError);
synthetics.addExecutionError(requestFailedError, null);
});
try {
stepName = new URL(url).hostname;
} catch (e) {
const errorString = `Error parsing url: ${url}. ${e}`;
log.error(errorString);
/* If we fail to parse the URL, don't emit a metric with a stepName based on it.
It may not be a legal CloudWatch metric dimension name and we may not have an alarms
setup on the malformed URL stepName. Instead, fail this step which will
show up in the logs and will fail the overall canary and alarm on the overall canary
success rate.
*/
throw e;
}
await synthetics.executeStep(stepName, async function () {
const sanitizedUrl = syntheticsLogHelper.getSanitizedUrl(url);
/* You can customize the wait condition here. For instance, using 'networkidle2' or 'networkidle0' to load page completely.
networkidle0: Navigation is successful when the page has had no network requests for half a second. This might never happen if page is constantly loading multiple resources.
networkidle2: Navigation is successful when the page has no more then 2 network requests for half a second.
domcontentloaded: It's fired as soon as the page DOM has been loaded, without waiting for resources to finish loading. If needed add explicit wait with await new Promise(r => setTimeout(r, milliseconds))
*/
const response = await page.goto(url, { waitUntil: ['networkidle0'], timeout: 30000});
The code for a heartbeat blueprint canary is to check the existence of a single webpage, and if the webpage pretty much responds with a 200 OK or not.
If the frontend webservers are down, we'll be able to see that the canary will show it as Failed. However, if a component of the webpage is unavailable, the canary will not mark it as a Failure.
I'd recommend that you try other blueprints for your purposes. In this case, it looks like you want to know whenever the website doesn't look the same exact way it did the last time. This is possible using the Visual monitoring blueprint as it can allow you to compare screenshots of the website and use a baseline screenshot for comparison.
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos
Thanks. I was hoping there would be a way to add it via scripting to just fail the heartbeat if any of the out-of-band HTTP requests fail, as its clear the runtime knows about it and is logging it.
A visual comparison should work but could possibly get tripped up if the vendor changes their API definition.
Its probably a weird edge case as I'm still not sure why our vendor's swagger UI page will load while it can't reach its own data file and the API isn't responding, usually as you had said, its either up or down and heartbeat has been great for that.