Alerting policies exist in dynamic and complex environments, so using them effectively requires an understanding of some of the variables that can affect their behavior. The metrics and resources monitored by conditions, the duration windows for conditions, and the notification channels can each have an effect.
This page provides some additional information to help you understand the behavior of your alerting policies.
The alignment period and the duration
The alignment period and the duration window are two fields that you set when specifying a condition for an alerting policy. This section provides a brief illustration of the meaning of these fields.
The alignment period is a look-back interval from a particular point in time. For example, if the alignment period is five minutes, then at 1:00 PM, the alignment period contains the samples received between 12:55 PM and 1:00 PM. At 1:01 PM, the alignment period slides one minute and contains the samples received between 12:56 PM and 1:01 PM.
To illustrate the effect of the alignment period on a condition in an alerting
policy, consider a condition that is monitoring a metric with a sampling period
of one minute. Assume that the alignment period is set to five minutes and that
the aligner is set to
sum. Finally, assume that the time series data is
unacceptable if the aligned value is greater than two for a duration of three
minutes, and that the condition is evaluated every minute.
The following figure illustrates several sequential evaluations of the condition:
Each row in the figure illustrates a single evaluation of the condition. The
time series data is shown. The points in the alignment period are shown with
blue dots, all older dots are gray. Each row displays the aligned value and
whether this value is above the threshold of two. For the row labeled
the aligned value computes to 1, which is below the threshold.
At the next evaluation, the sum of the samples in the alignment period is 2.
On the third evaluation, the sum is 3, and
is greater than the threshold. The condition evaluator also starts the
duration window timer.
To prevent an alerting policy from being triggered by transient anomalies, you can configure the condition to require that the time series be unacceptable for a period of time. This period is called the duration or the duration window. If you are using the Google Cloud Console, the For field in the Configuration pane corresponds to the duration window.
The previous figure illustrated three evaluations of the condition. At the
start + 2m, the aligned value was above the threshold; however the
condition isn't met because the duration window is set to three minutes. The
following figure illustrates the results for the next evaluations of the
As illustrated, even though the aligned value is above the threshold at time
start + 2m, the condition isn't met until the aligned value is above the
threshold for three minutes. That occurs at time
start + 5m.
The figure illustrates that the alignment period determines how many data samples are combined with the aligner. If you choose a long period, many samples are combined. If you choose a short period, it's possible that only one data point is in the interval. In contrast, the duration window specifies how long the aligned values must be above the threshold before the condition is met. If the duration window is set to 0, then a single aligned value being above the threshold means the condition is met.
For clarity, the previous example omitted the possibility of combining the aligned data points from multiple time series into a single measurement. It is that measurement that is compared to the threshold to determine if the time series has unacceptable values.
A condition resets its duration window each time a measurement doesn't satisfy the condition. This behavior is illustrated in the following example:
Example: This policy specifies a five-minute duration window.
If HTTP response latency is higher than two seconds,
and if the latency is above that threshold for five minutes,
open an incident and send email to your support team.
The following sequence illustrates how the duration window affects the evaluation of the condition:
- The HTTP latency is below two seconds.
- For the next three consecutive minutes, HTTP latency is above two seconds.
- In the next measurement, the latency falls below two seconds, so the condition resets the duration window.
- For the next five consecutive minutes, HTTP latency is above two seconds, so the condition is met and the policy is triggered.
Set the duration window to be long enough to minimize false positives, but short enough to ensure that incidents are opened in a timely manner.
Policies with multiple conditions
An alerting policy can contain up to 6 conditions.
If you are using the Cloud Monitoring API or if your alerting policy has multiple conditions, then you must specify when violations of the individual conditions result in an incident being opened:
- If you are using the Google Cloud Console, you use the Policy triggers field.
- If you are using the Cloud Monitoring API, then you use the
This table lists the settings in the Cloud Console, the equivalent value in the Cloud Monitoring API, and a description of each setting:
Policy triggers value
|Cloud Monitoring API
|Any condition is met
||An incident is opened if any resource violates any of the conditions.|
|All conditions are met||
||An incident is opened if each each condition is violated by at least one resource, even if a different resource violates each condition.|
|All conditions are met
on matching resources
||An incident is opened if each condition is violated by the same resource. This setting is the most stringent combining choice.|
In this context, the term met
means that the condition's configuration evaluates to true. For example,
if the configuration is
Any time series is above 10 for 5 minutes,
then when this statement evaluates to true, the condition is met.
Consider a Google Cloud project that contains two VM instances, vm1 and vm2. Also, assume that you create an alerting policy with 2 conditions:
- The condition named
CPU usage is too highmonitors the CPU usage of the instances. This condition is met when the CPU usage of any instance is above 100ms/s for 1 minute.
- The condition named
Excessive utilizationmonitors the CPU utilization of the instances. This condition is met when the CPU utilization of any instance is above 60% for 1 minute.
Initially, assume that both conditions evaluate to false.
Next, assume that the CPU usage of vm1 exceeds 100ms/s for 1 minute. This
CPU usage is too high to evaluate to true. If the
conditions are combined with Any condition is met, then an incident
is created because a condition is met. If the conditions are combined with
All conditions are met or All conditions are met on matching resources,
then an incident isn't created. These combiner choices require that both
conditions evaluate to true.
Now assume that the CPU usage of vm1 continues to be above 100ms/s and that the CPU utilization of vm2 exceeds 60% for 1 minute. The result is that both conditions evaluate to true. The following describes what occurs based on how the conditions are combined:
Any condition is met: A second incident is created because vm2 is causing
Excessive utilizationto evaluate to true.
When a condition's configuration evaluates to true, the alerting policy keeps a record of the monitored resource and the condition. An incident is created based on the pairing of the resource and the condition. Therefore, vm1 causing
CPU usage is too highto be true and vm2 causing
CPU usage is too highto be true are distinct events. An incident is created for each event.
All conditions are met: An incident is created because both conditions evaluate to true.
In this example, vm1 causes
CPU usage is too highto be true while vm2 is causing
Excessive utilizationto evaluate to true. Consequently, an incident is created.
All conditions are met on matching resources: An incident isn't created in this case because neither vm1 nor vm2 caused both conditions to evaluate to true. For an incident to be created for this combiner choice, the same VM instance must cause both conditions to evaluate to true.
Disabled alerting policies
Alerting policies can be temporarily paused and restarted by disabling and enabling the policy. For example, if you have an alerting policy that notifies you when a process is down for more than 5 minutes, you can disable the alerting policy when you take the process down for upgrade or other maintenance.
Disabling an alerting policy prevents the policy from triggering (or resolving) incidents, but it doesn't stop Cloud Monitoring from evaluating the policy conditions and recording the results.
Suppose the monitored process is down for 20 minutes for maintenance. If you restart the process and re-enable the alerting policy immediately, it recognizes that the process hasn't been up for the last 5 minutes and opens an incident.
When a disabled policy is re-enabled, Monitoring examines the values of all conditions over the most recent duration window, which might include data taken before, during, and after the paused interval. Policies can trigger immediately after resuming them, even with large duration windows.
Alerting policies, particularly those with metric-absence or “less than” threshold conditions, can appear on the Incidents pane of the Alerting window, and appear to have triggered prematurely or incorrectly.
This occurs when there is a gap in the data, but it isn't always easy to identify such gaps. Sometimes the gap is obscured, and sometimes it is corrected.
In charts, for example, gaps in the data are interpolated. Several minutes of data may be missing, but the chart connects missing points for visual contiguity. Such a gap in the underlying data may be enough to trigger an alerting policy.
Points in logs-based metrics can arrive late and be backfilled, for up to 10 minutes in the past. This effectively corrects the gap; the gap is filled in when the data finally arrives. Thus, a gap in a logs-based metric that can no longer be seen could have caused an alerting policy to trigger.
Metric-absence and “less than” threshold conditions are evaluated in real time, with a small query delay. The status of the condition can change between the time it is evaluated and the time the corresponding incident is visible in Monitoring.
Partial metric data
If measurements are missing (for example, if there are no HTTP requests for a couple of minutes), the policy uses the last recorded value to evaluate conditions.
- A condition specifies HTTP latency of two seconds or higher for five consecutive minutes.
- For three consecutive minutes, HTTP latency is three seconds.
- For two consecutive minutes, there are no HTTP requests. In this case, a condition carries forward the last measurement (three seconds) for these two minutes.
- After a total of five minutes the policy triggers, even though there has been no data for the last two minutes.
Missing or delayed metric data can result in policies not alerting and incidents not closing. Delays in data arriving from third-party cloud providers can be as high as 30 minutes, with 5-15 minute delays being the most common. A lengthy delay—longer than the duration window—can cause conditions to enter an "unknown" state. When the data finally arrives, Cloud Monitoring might have lost some of the recent history of the conditions. Later inspection of the timeseries data might not reveal this problem because there is no evidence of delays once the data arrives.
You can minimize these problems by doing any of the following:
- Contact your third-party cloud provider to see if there is a way to reduce metric collection latency.
- Use longer duration windows in your conditions. This has the disadvantage of making your alerting policies less responsive.
Choose metrics that have a lower collection delay:
- Monitoring agent metrics, especially when the agent is running on VM instances in third-party clouds.
- Custom metrics, when you write their data directly to Cloud Monitoring.
- Logs-based metrics, if logs collection is not delayed.
Incidents per policy
An alerting policy can apply to many resources, and a problem affecting all resources can trigger the policy and open incidents for each resource. An incident is opened for each time series that violates a condition.
To prevent overloading the system, the number of incidents that a single policy can open simultaneously is limited to 5000.
For example, if a policy applies to 2000 (or 20,000) Compute Engine instances, and something causes each to violate the alerting conditions, then only 5000 incidents are opened. The remaining violations are ignored until some of the open incidents for that policy resolve.
Notifications per incident
A notification is sent out for each incident triggered by the alerting policy. Another notification is sent for each incident when it is resolved. An incident is opened for each time series that violates a condition, so each new incident results in a notification.
If a policy contains only one condition, then one notification is sent when the incident is initially opened, even if subsequent measurements continue to meet the condition.
If a policy contains multiple conditions, it may send multiple notifications depending on how you set up the policy:
If a policy triggers only when all conditions are met, then the policy sends a notification only when an incident initially opens.
If a policy triggers when any condition is met, then the policy sends a notification each time a new combination of conditions is met. For example:
- ConditionA is met, and an incident opens and a notification is sent
- The incident is still open when a subsequent measurement meets both ConditionA and ConditionB. In this case, the incident remains open and another notification is sent.
Notification latency is the delay from the time a problem first starts until the time a policy is triggered.
The following events and settings contribute to the overall notification latency:
Metric collection delay: The time Cloud Monitoring needs to collect metric values. For Google Cloud values, this is typically negligible. For AWS CloudWatch metrics, this can be several minutes. For uptime checks, this can be an average of two minutes (from the end of the duration window).
Duration window: The window configured for the condition. Note that conditions are only met if a condition is true throughout the duration window. For example, if you specify a five-minute window, the notification is delayed at least five minutes from when the event first occurs.
Time for notification to arrive: Notification channels such as email and SMS themselves may experience network or other latencies (unrelated to what's being delivered), sometimes approaching minutes. On some channels—such as SMS and Slack—there is no guarantee that the messages are be delivered.