I want to trigger an alarm when 30% of requests take more than 10s TargetResponseTime within a period of 5minutes in AWS cloud watch
Check available statistics https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html
Percentile rank (PR) should work in your case.
try with PR(10:300) and set threshold to 30%
Related
I am running a Kusto Query in my Azure Diagnostics where I am querying logs of last 1 week and the query times out after 10 mins. Is there a way I can increase the timeout limits? if yes can someone please guide me the steps. I downloaded Kusto explorer but couldnt see any easy way of connecting my Azure cluster. Need help as how can i increase this timeout duration from inside Azure portal for query I am running?
It seems like 10 minutes are the max value for timeout.
https://learn.microsoft.com/en-us/azure/azure-monitor/service-limits
Query API
Category
Limit
Comments
Maximum records returned in a single query
500,000
Maximum size of data returned
~104 MB (~100 MiB)
The API returns up to 64 MB of compressed data, which translates to up to 100 MB of raw data.
Maximum query running time
10 minutes
See Timeouts for details.
Maximum request rate
200 requests per 30 seconds per Azure AD user or client IP address
See Log queries and language.
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/api/timeouts
Timeouts
Query execution times can vary widely based on:
The complexity of the query
The amount of data being analyzed
The load on the system at the time of the query
The load on the workspace at the time of the query
You may want to customize the timeout for the query.
The default timeout is 3 minutes, and the maximum timeout is 10 minutes.
I'm looking Mediatailor metrics in Cloudwatch and found that for "Avail" group there are: duration, observedDuration, filledDuration, observedFilledDuracion, fillRate, observedFillRate.
For example for duration, documentation says that duration is a "planned" value and observedDuration is a "observed" value but it is not clear for me. I guess that planned is according with the AD marker in the manifest and observed is from the ad insertion step itself (is it correct?) I guess that "observed" values are more accurate.
Anyway I suppose that "planned" and "observed" values should be similar but usually this is not the case. These are a couple of examples for the values
Filled are similar but duration and fillRate are really different so I don't understand which I should to use
I guess that planned is according with the AD marker in the manifest and observed is from the ad insertion step itself (is it correct?) I guess that "observed" values are more accurate.
Yes, the observed values are what MediaTailor takes action on based on the VAST response from the Ad Decision Server (ADS). Planned is the value received from the Origin via SCTE-35 messaging.
Per the following documentation: https://docs.aws.amazon.com/mediatailor/latest/ug/monitoring-cloudwatch-metrics.html
Duration - The planned total number of milliseconds of ad avails
within the CloudWatch time period. The planned total is based on the
ad avail durations in the origin manifest.
ObservedDuration - The observed total number of milliseconds of ad
avails that occurred within the CloudWatch time period.
Avail.ObservedDuration is emitted at the end of the ad avail, and is
based on the duration of the segments reported in the manifest during
the ad avail.
To continue your example regarding the Duration metric let's say that for a set period of time the Origin server sends a manifest with a single Ad Break for 90 seconds. MediaTailor will perform a request to the ADS asking for 90 seconds of content. The ADS returns a VAST response that includes a 45 second Ad and a 30 second Ad for a total of 75 seconds. MediaTailor will report to CloudWatch that, for the set period of time, the Duration of all Avails planned by the Origin server was 90 seconds, but the Observed Duration provided by the ADS was 75 seconds.
The documentation goes into further detail regarding each metric and even provides some examples.
I am streaming data from devices and I want to use the LAG function to identify the last value received from a particular device. The data is not streamed at a regular period and in rare cases it could be days between receiving data from a device.
Is there a maximum period for the LIMIT DURATION clause?
Is there any down-side to having long LIMIT DURATION periods?
There is no maximum period for LIMIT DURATION in the language. However it is limited by amount of data the input source can hold - e.g. 1 day is default retention policy for Event Hub (can be increased in configuration).
When job is being started, Azure Stream Analytics reads up to LIMIT DURATION amount of data from the source to make sure it has correct value for the LAG at job start time. If data volume is high, this can increase job start time.
If you need to use data that is more than several days old, it may make more sense to use it as a reference data (which can be updated at daily intervals for example)
today I created a small batch of 20 categorization HITs with the name Grammatical or Ungrammatical using the web UI. Can you tell me the easiest way to manage this batch so that I can reduce its time allotted to 15 minutes from 1 hour and remove also remove the categorization of masters. This is a very simple task that's set to auto-approve within 1 hour, and I am fine with that. I just need to make it more lucrative for people to attempt this at the penny rate.
You need to register a new HITType with the relevant properties (reduced time and no masters qualification) and then perform a ChangeHITTypeOfHIT operation on all of the HITs in the batch.
API documentation here: http://docs.aws.amazon.com/AWSMechTurk/latest/AWSMturkAPI/ApiReference_ChangeHITTypeOfHITOperation.html
In http://code.google.com/intl/es-ES/appengine/docs/quotas.html#Channel you
can read that with billing enabled the maximum channel created rate is 60
creations/minute. Does it mean that we can created only 86,400
channels/day. It's very low rate, isn't it? And if i have estimated that I
could have peaks of for example: 4,000 creations/minute... What i can do?
60 creations/minute are few creations if the channels are 1to1... Is this
correct?
My interpretation of that section is that you will NOT be able to create 4k connections per minute. Here is how I would think about it: over ANY 1-minute period, no more than 60 channels can be created. For example, you can create 60 channels at time T. Then, for the next 60 seconds you won't be able to create any. Or, you can create 30 at time T. Then, every 2 seconds, create a channel.
I believe another way to think about this is in terms of the token bucket algorithm.
Anyway, I believe you can fill out this form to request a higher limit. There is a link to that form from the docs that you linked to in your question.