Hello, and welcome to SLI-Based Alerting Policies. 

Organizations use GCP Cloud Monitoring to collect metrics on the performance of their service infrastructure. For example, an organization might use “Request Count” to track the number of HTTP requests per minute for a website or web app that result in 2xx or 5xx responses. If only interested in information on the latency for HTTP 2xx responses, an organization might want to monitor “Response latencies”.

Such performance metrics are automatically identified based on a set of known service types. These service types include App Engine, Istio on Google Kubernetes Engine, and Cloud Endpoints. It’s also possible to define custom service types and to select specific performance metrics for them.

Whether you are interested in the known service types or custom service types, the performance metrics that you track are the basis of the SLIs for your service. An SLI, or service level indicator, refers to the performance of a specific part of your service – and because the performance metrics are automatically identified for services on App Engine, Istio on Google Kubernetes Engine, and Cloud Endpoints, useful SLIs are already known for those services. For example, let’s assume you support a service that requires request-count or response-latencies metrics. In such a case, standard SLIs can be derived from those metrics. You could derive an availability SLI by comparing the number of successful responses to the total number of all responses. A latency SLI could be derived by comparing the number of calls below a certain latency threshold to the total number of all calls.

Service-specific SLIs can also be established when you need to track some other measure of what “good performance” means. Such service-specific SLIs will usually fall into one of two different categories: Request-Based SLIs and Windows-Based SLIs.

Request-based SLIs are used when “good service” is measured by “units of service”. For example, a request-based SLI might measure the number of successful HTTP requests for a website. 

Windows-based SLIs, however, are used when “good service” is measured by counting the number of time periods where performance meets a specific criteria. An example of a Windows-based SLI would be something like response latency that’s below a specified threshold.

Before you create an alerting policy, you need to decide what you want to monitor, when the alerting policy should be triggered, and how you want to be notified. 

The table on your screen shows what settings need to be defined when creating an alerting policy.

• Title: The name and a brief description of the alerting policy
• Summary: A brief description of the alerting policy
• Target pane fields: Specify what is being monitored and how the data is aggregated
• Configuration fields: Specify when the alerting policy triggers

Notice we have a title, a summary, the target pane fields, and the configuration fields. The title is pretty self explanatory. It is the name and a brief description of the alerting policy being created. The summary is a brief description of the alerting policy. The target pane fields are used to specify what you want to monitor and how the data is aggregated, while the configuration fields are used to specify when the alerting policy triggers.

Alerting policies can also be managed programmatically via the API. However, this feature is currently in beta at the time of this recording, so I don’t want to get into too much detail. To ensure you have the latest information on this topic, visit the URL that you see on your screen.

Join me in the next lesson, where I’ll show you how to create an alerting policy.