I don't understand why an incident is being triggered looking at the following Policy details:
In the screenshot you can see that the incident is supposed to trigger after an absence time of 8 hours. The timeseries is representing the activity of the log-based metric of the last day. There is clearly no absence. Why is an incident being triggered? (you can see it in the incident section)
edit
adding more screenshot
Policy details over a week
Incidents details
Related
I have set up a budget alert using Azure Portal ,I have defined my budget as 400$ and frequency as 120$ .I have received the alert notification by mail .But my concern here is ,that in alert mail the actual value is 240 which is much more than 120 . I want the alert to be triggered right immediately when the value goes above 120(Threshold Value) .
Is there any approach where I can change/check the Frequency of evaluation of Budget Alert defined .
Azure usage data is not updated in real-time
https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/understand-cost-mgt-data#cost-and-usage-data-updates-and-retention
I don't think there is an option to increase the evaluation frequency of the Alert. Even if you could do it, the cost data would be still delayed.
I would like my client to monthly subscribe to a product (30 days billing period), with a maximum of 3 years : so 3 * 12 = 36 reccurencies. So after 3 years, his subscription is automatically canceled.
I could find that feature in Paypal, but did not find that feature in the stripe.
regards
When creating a Subscription, if you calculate the exact time in the future that you want it to cancel then you can provide that timestamp via the cancel_at parameter here. However, if you use that approach and don't set cancel_at to the exact end of a billing period, then the final invoice will have a prorated amount.
You can also use Subscription Schedules to achieve this, which are objects that allow you to schedule changes that will be made to your Subscriptions in the future. You could use these to schedule a future phase to set cancel_at_period_end to true for your Subscription, causing it to automatically cancel at the end of that billing period. When creating the Subscription Schedule, you can use phases.iterations to easily set the duration of the phases to match your needs.
You can read more about Subscription Schedules here:
https://stripe.com/docs/billing/subscriptions/subscription-schedules
I'm new to Application Insights Alerts and think I may have misconfigured something. I need to be alerted when an Azure Function fails to execute.
Setup App Insights Alert
Trigger alert when count of failures > 1 within a 60min period
Alert triggered 3x in the past week
No failure conditions have existed on this Function since 12/2/2020
How do I correlate an App Insights alert with its corresponding log file?
Seems like this should be a "one-click thing" but I must be missing it somewhere.
EDIT 1: Here is the exceptions table. Same findings; no fails since 12/2.
EDIT 2: Here is the dependencies table. Nothing found in last 30d.
EDIT 3: Per the recommendation on another post, I changed the alert from the out-of-the-box Metric to a Custom log search.
I left the original alert (that failed for no reason) in place alongside the new one.
The original one just failed again for no reason
Details:
Alert emails say:
Start 2021-01-06 8:22 UTC
End 2021-01-06 11:22 UTC
Function Monitor shows Function ran SUCCESSFULLY at:
2021-01-06 08:13:21.368 UTC
2021-01-06 08:13:21.372 UTC
Detailed logs show the function ran successfully
At this point, I'm going to say the Metric version of alerts should be discarded. What ever its logic is based on has created false positives for me a number of times now.
Stick to the custom log search
The alert is triggered when at least 2 (because that is what the treshold of > 1 means) failures occur in a timespan of 1 hour. All three alerts of last week (2nd screenshot) where triggered on a different day.
Are you sure you don't need to set the threshold to Greater than 0 so that each failure triggers the alert?
UPDATE:
the actual problem is different from what I've described. I'll provide and update/edit to this ticket once we'll resolve the issue. More details may be found at this thread - https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Reliably-trigger-alerts-for-Log-Analytics-log-entries/m-p/319315/highlight/false#M1224
Original question:
We use Azure Monitor to create alerts based on logs in Log Analytics. For this we choose our Log Analytics account as a "RESOURCE", then choose "Custom log search" signal name for "CONDITION". Alert logic - "Number of results greater than 0".
Sample query:
search *
| where ResourceProvider == "MICROSOFT.DATAFACTORY" and status_s == "Failed"
For Period and Frequency lets set 15 minutes. All looks simple, but...
The issue: described above setup does not work (it works sometimes), because alerts are fired only sometimes, a lot of them are missed which is completely unacceptable behavior.
If we set Period = Frequency = 5 minutes we basically miss almost every event. Period = Frequency = 15 minutes works better, but still a lot of events are missing. Period = Frequency = 30 works even better, but all this looks weird.
Important notice - logs are collected from Data Factory V2 into Log Analytics. I suspect that alert misses are due to the fact that logs are delivered to Log Analytics with some delay (up to several minutes). So when Azure Monitor evaluates alert query for the last 15 minutes (Period=15) it might be that most resent log entries are still not in Log Analytics. When next query evaluation is executed in 15 minutes it will miss the logs that were ingressed with a delay for prev 15 minutes interval. Is this assumption correct? If so, this is very weird - how then we supposed to configure Period and Frequency values? If I set Period > Frequency (e.g. Period = 30 and Frequency = 5, which means "evaluate expression every 5 minutes, take data for last 30 minutes from current time") then we get multiple duplicated alerts because Period is larger than Frequency so there is a big chance of log search query returning the same log entries every 5 minutes - this is highly undesirable behavior.
Issue happened to be with a buggy bahavior of ARM template creating alerts. Thanks to Stanislav Zhelyazkov it has been nailed down and resolved - I use alternative ARM API now and it seems to work fine. More details on the topic may be found here - https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Reliably-trigger-alerts-for-Log-Analytics-log-entries/m-p/309610.
I tried to pull the Azure resource usage data for billing metrics. I followed the steps as mentioned in the blog to get Usage data of resources.
https://msdn.microsoft.com/en-us/library/azure/mt219001.aspx
Even If I set "start and endtime" parameter in the URL, its not take effect. It returns entire output [ from resource created/added time ].
For example :
https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Commerce/UsageAggregates?api-version=2015-06-01-preview&reportedStartTime=2017-03-03T00%3a00%3a00%2b00%3a00&reportedEndTime=2017-03-04T00%3a00%3a00%2b00%3a00&aggregationGranularity=Hourly&showDetails=true"
As per the above URL, it should return the data between "2017-03-03 to 2017-03-04". But It shows the data from 2nd March [ 2017-03-02]. don't know why this return entire output and time filter section is not working.
Note : Endtime parameter value takes effect, mean it shows the output upto what mentioned in the endtime. But it doesn't consider the start time.
Anyone have a suggestion on this.
So there are a few things to consider:
There is usage date/time and then there is reported date/time.
Former tells you the date/time when the resources were used while the
latter tells you the date/time when this information was received by
the billing sub-system. There will be some delay in when the
resources used versus when they are reported. From this link:
Set {dateTimeOffset-value} for reportedStartTime and reportedEndTime
to valid dateTime values. Please note that this dateTimeOffset value
represents the timestamp at which the resource usage was recorded
within the Azure billing system. As Azure is a distributed system,
spanning across 19 datacenters around the world, there is bound to be
a delay between the resource usage time (when the resource was
actually consumed) and the resource usage reported time (when the
usage event reached the billing system) and callers need a predictable
way to get all usage events for a subscription for a given time
period.
The query only lets you search for reported date/time and there is no provision for usage date/time. However the data returned back to you contains usage date/time and not the reported date/time.
Long story short, because of the delay in propagating the usage information to the billing sub-system, the behavior you're seeing is correct. In my experience, it takes about 24 hours for all the usage information to show up in the billing sub-system.
The way we handle this scenario in our application is we fetch the data for a longer duration and then pick up only the data we're interested in seeing. So for example, if I need to see the data for 1st of March then we query the data for reported date/time from 1st March to say 4th March (i.e. today's date) and then discard any data where usage date is not 1st of March.
If we don't find any data (which is quite possible and is happening in your case as well), we simply tell the users that usage information is not yet available.