<commit_before># Stackdriver Monitoring

## Backend

Using the `Stackdriver` backend class, you can query any metrics available in Stackdriver Monitoring to create an SLO.

The following methods are available to compute SLOs with the `Stackdriver` backend:

* `good_bad_ratio` for metrics of type `gauge`.
* `exponential_distribution_cut` for metrics of type `distribution`.

### Good / bad ratio

The `good_bad_ratio` method is used to compute the ratio between two metrics:

- **Good events**, i.e events we consider as 'good' from the user perspective.
- **Bad or valid events**, i.e events we consider either as 'bad' from the user perspective, or all events we consider as 'valid' for the computation of the SLO.

This method is often used for availability SLOs, but can be used for other purposes as well (see examples).


### Exponential distribution cut

The `exponential_distribution_cut` method is used for Stackdriver distribution-type metrics, which are usually used for latency metrics.

A distribution metric records the **statistical distribution of the extracted values** in **histogram buckets**. The extracted values are not recorded individually, but their distribution across the configured buckets are recorded, along with the `count`, `mean`, and `sum` of squared deviation of the values.

In `Stackdriver Monitoring`, there are three different ways to specify bucket boundaries:
* **Linear:** Every bucket has the same width.
* **Exponential:** Bucket widths increases for higher values, using an exponential growth factor.
* **Explicit:** Bucket boundaries are set for each bucket using a bounds array.

***Note:*** *Currently the SLO generator only support the exponential distributions. Those are the most common metrics on GCP and the reason we have priviledge their support, but we plan to add support for linear and explicit distribution metrics as well.*

### Examples

Complete examples using the Stackdriver backend are available in the `samples/` folder:

- [slo_sd_pubsub_throughput.yaml](../samples/slo_sd_pubsub_throughput.yaml)
- [slo_sd_gae_app_availability.yaml](../samples/slo_sd_gae_app_availability.yaml)
- [slo_sd_gae_app_latency64ms.yaml](../samples/slo_sd_gae_app_latency64ms.yaml)
- [slo_sd_gae_app_latency724ms.yaml](../samples/slo_sd_gae_app_latency724ms.yaml)

The following examples show how to populate the `backend` section for the Stackdriver backend.

**&rightarrow; Example 1: Ratio of Pub/Sub acknowledged messages over all Pub/Sub messages**

> We want to compute the proportion of messages that are acknowledged from our Pub/Sub subscriptions.
>
> -- <cite>SRE Engineer</cite>

`Stackdriver Monitoring` has two service-level metrics we can use to measure this:
<commit_msg>Remove restriction on exponential distribution metrics<commit_after># Stackdriver Monitoring

## Backend

Using the `Stackdriver` backend class, you can query any metrics available in Stackdriver Monitoring to create an SLO.

The following methods are available to compute SLOs with the `Stackdriver` backend:

* `good_bad_ratio` for metrics of type `gauge`.
* `exponential_distribution_cut` for metrics of type `distribution`.

### Good / bad ratio

The `good_bad_ratio` method is used to compute the ratio between two metrics:

- **Good events**, i.e events we consider as 'good' from the user perspective.
- **Bad or valid events**, i.e events we consider either as 'bad' from the user perspective, or all events we consider as 'valid' for the computation of the SLO.

This method is often used for availability SLOs, but can be used for other purposes as well (see examples).


### Distribution cut

The `exponential_distribution_cut` method is used for Stackdriver distribution-type metrics, which are usually used for latency metrics.

A distribution metric records the **statistical distribution of the extracted values** in **histogram buckets**. The extracted values are not recorded individually, but their distribution across the configured buckets are recorded, along with the `count`, `mean`, and `sum` of squared deviation of the values.

In `Stackdriver Monitoring`, there are three different ways to specify bucket boundaries:
* **Linear:** Every bucket has the same width.
* **Exponential:** Bucket widths increases for higher values, using an exponential growth factor.
* **Explicit:** Bucket boundaries are set for each bucket using a bounds array.


### Examples

Complete examples using the Stackdriver backend are available in the `samples/` folder:

- [slo_sd_pubsub_throughput.yaml](../samples/slo_sd_pubsub_throughput.yaml)
- [slo_sd_gae_app_availability.yaml](../samples/slo_sd_gae_app_availability.yaml)
- [slo_sd_gae_app_latency64ms.yaml](../samples/slo_sd_gae_app_latency64ms.yaml)
- [slo_sd_gae_app_latency724ms.yaml](../samples/slo_sd_gae_app_latency724ms.yaml)

The following examples show how to populate the `backend` section for the Stackdriver backend.

**&rightarrow; Example 1: Ratio of Pub/Sub acknowledged messages over all Pub/Sub messages**

> We want to compute the proportion of messages that are acknowledged from our Pub/Sub subscriptions.
>
> -- <cite>SRE Engineer</cite>

`Stackdriver Monitoring` has two service-level metrics we can use to measure this:

{'fraction_non_alphanumeric': 0.07565915170042033, 'fraction_numerical': 0.004203286205578907, 'mean_word_length': 5.269461077844311, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2838190', 'n_tokens_mistral': 1421, 'n_tokens_neox': 1330, 'n_words': 638}