I have configured an Azure Web Application Monitoring rule such that if there are more than 30 requests over a five minute period, then an alert should fire which should both send me an email and trigger a webhook.
Problem is, the alert doesn't fire even when the parameters for the alert are clearly satisfied. I took a screenshot of the traffic graph after I made over 30 requests to the server within a five-minute window. I've also included the specific configuration menus for this alert.
How can I make this alert fire?
I checked one of my alerts a similar one that was set to a threshold of 5 mins for response time, I find that these alerts were fired , if my response time for a give requests exceed a certain time (12MS) and that if it had happened for a period of 5 minutes, email needs to be sent. I have attached a snapshot as to when this happened to help understand what this might be - so in your case , to measure if the requests were greater than 30 at say 12:00PM - until 12:05 PM - (ie) for a period of 5 mins, your alert would fire - if it did not, then you may need to check something else.
So my guess here is that if there was a flat line # more than 30 for a period of 5 mins - meaning if you had requests greater than 30 for a continuous period of of 5 mins, your alert would and should work.
Related
we are evaluating logic apps for long running workflows
our process is as follows
once we receive a request (http request trigger), we call another service with the webhook action sending a callback url, now the process might take any where between 10 to 15 days to complete.
Question
can the logic app wait for 10 to 15 days ?
what happens if the callback does not happen ?
Thanks -Nen
A single HTTP request from Logic Apps will time out after 2 minutes. The default run time limit for all synchronous actions in multi-tenant Logic App is 2 minutes.
can the logic app wait for 10 to 15 days --> no
what happens if the callback does not happen ? --> Action
patterns
check below links -
calling-long-running-functions-from-logic-apps
Limits and configuration information for Azure Logic Apps
There are two points that need to be made when answering your question.
Firstly, the standard amount of time that a HTTP trigger can run for is two minutes (https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config?tabs=azure-portal#run-duration-and-retention-history-limits), but, that's when the request/response architecture is synchronous based. If you want to fire it in an asynchronous way (like you do) then you need to provide a Response to the calling application prior to the two minute timeout. Like thus ..
Secondly, You can see from the above image that a delay has been running for 11 minutes at the time of posting this answer which is more than the 2 minutes restriction if the response wasn't provided back.
I suspect (and would need to confirm but it would take me 10 days) that a webhook will perform for your full 10 to 15 days given there is absolutely no evidence to show it doesn't (i.e. the documentation does not explicitly state it). I believe it will stick to the 90 day period as per the full length of any multi-tenant Logic App implementation.
I'm working on configuring an Azure Log Analytics alert (using KQL) to capture the IIS Stop & Start events (from Events table) in my OMS Workspace, and if the alert query finds that there's no corresponding IIS Start event log generated from a PaaS Role for a particular IIS Stop event log- the user should get notified by an alert so that he can bring IIS back up.
Problem: Let’s say I setup my alert to run over a Time Period & Frequency of 15mins. If the alert triggered at 10:30AM, that means it will scan the IIS logs from 10:15:01 AM to 10:29:59 AM. Now, suppose an IIS Stop event got logged in around 10:28 AM, then the respective IIS Start log (if any) will be logged in after a couple of minutes around 10:31AM or 10:32 AM – and hence it will go out of the alert’s monitoring time period. This will create a false positive failure scenario. (IIS got started back but my alert didn’t captured the Start event log). And thus, it might lead to some unnecessary IIS Start/Reset operations on my PaaS roles.
Attaching a representative quick sketch to explain it figuratively.
Please let me know if there's any possible approach to achieve this. Any suggestions are welcome. Thanks in advance!
Current implementation as follows.
Here we can see False Alert generated at 10:30.
You can see the below approach, where we select last 10 minutes data(Overlapped) every 5 minutes.
For the below case you can generate the alert
See if its helping you.
I have created a AppService on Azure that runs on Tomcat. I'm using metrics for monitoring and set alert rule, that should send me an email, when error 4xx will occur. Nothing happens even though I've created more errors than rule needs to run alert.
Thanks, Dominik
According to your screenshot & the reference for Metric Definitions, it seems to be normal to not happen the event of sending mail, because your alert rule means the count of the HTTP 4xx event is greater than or equal to 5 times over the last 5 minutes, not average count per minute. So you can try to increase the threshold value or shorten the period to check the mail sender whether be triggered when the condition satisfied obviously. Meanwhile, if you doubt the alert trigger whether works fine, you can retrieve the logs via Azure CLI or Powershell.
Heroku says (free)
Must sleep 6 hours in a 24 hour period
Ok, that´s fine.
But can I influence the message or any text shown to the user like: "Hello user, unfurtunately the the website needs some rest, please try again from 6 a.m to 2 a.m ".
I can influence the uptime, because of sending a ping every 20 min.
I just found this:
... free dynos are allowed 18 hours awake per 24 hour period, and over the next few weeks we will begin to notify users of apps that exceed that limit ...
If you're using a CDN you could create a scheduled task that replaces the root page by a static page at a certain time of day, make sure the CDN updates to that page, and then spin down the app for 6 hours.
The docs for CloudFlare might be a good place to start learning how a CDN works and how to set it up (see: CloudFlare Support > Getting Started). Of course you could also use a different Content Delivery Network (CDN) service.
We are seeing some behaviour that we can’t understand with the servicebus and deadletters, and wonder if someone can give us some insight into how the rules work.
If I create a topic with a TTL of 5 mins (‘LongTopic’) which has 2 subscriptions, ‘Long’ with a TTL of 5 mins as well and ‘Short’ with a TTL of 5 seconds and then send a test message to the topic, then what we see is that we don’t get a dead letter on ‘Short’ after 5 seconds, but do after about 1 minute. So it seems I can override the topic TTL with a shorter TTL, but this doesn’t necessarily mean it will be dead lettered immediately upon the TTL expiring.
If I create a topic with a TTL of 5 seconds (‘ShortTopic’) which has 2 subscriptions, ‘Long’ with a TTL of 5 mins as well and ‘Short’ with a TTL of 5 seconds and then send a test message to the topic, then what we see is that we don’t get a dead letter on ‘Short’ after 5 seconds, but do after about 1 minute, and we also get a deadlettered message on the ‘Long’ after about a minute as well. So it seems I can’t override the topic TTL with a longer TTL in the subscription but again this doesn’t necessarily mean it will be dead lettered immediately upon the TTL expiring.
We have had topics with much longer TTL (3000 days) and sometimes we see messages which are not being forwarded from a subscription which are not deadlettering for 1.5hours despite the TTL on the subscription being 1 minute.
Does anyone have any idea if this is expected behaviour? Or have a link to the rules about when a message might be dead lettered?
When you set the dead letter info on a message, that tells Service Bus when a message should move to the dead letter queue or be completed (aka deleted)-- the choice depends on whether or not dead lettering is enabled on the queue or subscription. If you have an active receiver on the queue or subscription, then the dead letter time will match the dead letter interval within a few seconds. When you are just sending messages, the system runs with a background task that checks the queue or subscription on a regular cadence. As you have discovered experimentally, this check happens every 60s.
Your next question is likely "why doesn't this behave the way I want it to?" The Service Bus has been designed with a large number of optimizations to make sure that all messages are sent durably and that sends and receives happen as fast as possible. This means that we spend a lot of engineering time to be durable and fast for the primary scenarios- send/receive/browse messages.
The behavior you are seeing, which we call "proactive TTL", is actually quite new. It was first introduced into the Windows Azure Service in April 2013. Prior to this time, a user would have to actively receive on a queue or subscription in order to force the bookkeeping code to run.
At this time, you will not see the proactive TTL behavior for lightly used queues and subscriptions. If you have a message that expires in > 2 hours, that message won't move into the dead letter queue because the timer does not run on what are "idle entities". When the Service Bus is seeing an unusually high amount of usage, this window can shrink considerably-- as low as a 2 minute idle time on your entity will cause the proactive TTL timer to stop running.