NewRelicでSLOアラートを使ってみた件

## はじめに
この記事は[New Relic Advent Calendar 2024](https://qiita.com/advent-calendar/2024/newrelic "New Relic Advent Calendar 2024") シリーズ4 23日目の記事です。

はじめまして。kiyofujinです。Qiita初投稿でNewRelic Advent Calender 2024に参加させていただきます。普段は某企業でクラウドやObservabilityに関する業務に従事しています。とある業務で**NewRelicのSLOアラート**について検証する機会があったため、そのノウハウについて共有します。

## NewRelicにおけるアラート設定
NewRelicでは、[アラート条件](https://docs.newrelic.com/jp/docs/tutorial-create-alerts/create-an-alert/ "New Relicを使用したアラート条件の作成
")を利用することにより、取得したMetricsに対して**簡単にアラート設定を行うことができます。**

以下はEntityのSummary画面から飛ぶことができるアラート設定の画面になります。ここではMetricsのうち、Response Time, Throughput, Error rateに関するアラート設定を実施できます。Threshold typeとしてBaselineと書かれていますが、これは各Metricsがベースライン（通常状態）から逸脱した際にアラートを発出するものです。アプリケーションの通常状態から外れた場合にアラートを発出してくれるもので、エンジニアが事前に適切なThresholdを指定することが不要となります。また、Thresholdの指定も可能であるため、幅広いアラートの要件を反映させることが可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938964/d2b8442d-a4db-ceee-e2f5-e820e590a2dc.png)

アラート発出の際にはSlackやServiceNowなどの外部ツールに連携することもできます。このように**一連の運用ワークフローの環境構築が容易に行える**ことがNewRelicの強みの1つとなっています。

## NewRelicにおけるSLO設定
NewRelicではアラートと同じように、各サービスのSLOを設定し、可視化することができます。SLOの詳細については、Googleの[The Site Reliability Workbook](https://sre.google/workbook/implementing-slos/ "The Site Reliability Workbook")などをご覧いただければと思います。UI上からポチポチすることですぐにLatency (Response Time基準), Success (Error rate基準)に関するSLI, SLO設定を行ってくれます。デフォルトではLatencyのSLOが95%、SuccessのSLOが99.99%、Window Timeが7 daysの設定がされますが、もちろんカスタマイズ可能です。このようにNewRelicではすぐにSLOに関する設定を行え、監視を開始することが可能となります。アラートも含め、**「とりあえず試しに設定してみたい」ものについてすぐに設定できるのはNewRelicの大きな魅力の1つ**ですね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938964/1e6bbf20-f0a8-cefe-911e-ff1d7579f270.png)

## NewRelicにおけるSLOアラート設定
SLOアラートとは、SLOに対するエラーバジェットの消費に関するアラートです。SLOアラートの詳細についてはGoogleの[The Site Reliability Workbook - Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/ "The Site Reliability Workbook - Alerting on SLOs")をご覧ください。

NewRelicでは、SLI, SLOを作成した際に、SLOに関するアラート条件がアカウント単位（NewRelicのテナント単位）で作成されます。これは、Error budgetの残りに対してアラートが発出されるものです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938964/c4bbaed8-dc91-adb4-b127-7ce3990e3f89.png)

また、個別のSLOアラートについても容易に設定できます。ServiceLevelsの各項目より、以下のような[Create an alert condition]に飛ぶことができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938964/64989de8-7524-287d-b012-7fa7e6ced007.png)

SLOアラートを検討する際に重要となるのが、**Burn rate**です。Burn rateは、Error budgetの減り方を表す指標で、Burn rateが1の場合、Window Time内にエラーバジェットを全消費することを意味します。Error budgetの減り方、つまりBurn rateの大きさによりアラートを上げるものが、SLOアラートのメインとなります。NewRelicにより提案されるSLOアラートの種類は、Burn rateなどにより4種類に分かれます。

- Fast-burn rate
    - 1時間でError budgetを2%消費した際にアラート発出
- Slow-burn rate
    - 6時間でError budgetを5%消費した際にアラート発出
- Error budget consumption
    - Error budgetを80%消費した際にアラートを発出
- SLO compliance
    - SLIがSLOを下回った場合にアラート発出

なぜ4種類もあるかというと、Error budgetは、エラーが一斉に発生して一気に消費されることもあれば、一部のみにエラーが発生し、ゆっくり消費されることもあるからです。ゆっくり消費される場合でも、Error budgetを使い切ってしまう場合もあるため、このような状況に対してもアラートを発出し、気づく必要があります。Fast-burn rateはError budgetが一気に消費されている場合にアラートを発出するもの、Slow-burn rateはError budgetがゆっくり消費されている場合にアラートを発出するもの、Error budget comsumption、SLO complianceはError budget、SLOそのものに対するアラートとなります。

また、SLOアラートのカスタムも可能です。例えば、SLOのWindow Timeが30日、Error budgetが3日以内に枯渇しそうな場合、アラートを発出したい、というような要件にも対応が可能です。この場合のBurn rateは10となります。
（なぜBurn rateが10になるかは[こちら](https://sre.google/workbook/alerting-on-slos/ "The Site Reliability Workbook - Alerting on SLOs
")の[Alert on Burn Rate]をご覧ください）

カスタムを行う場合には、アラート条件の[Tell us where to look]画面で、Burn rateを取得するNRQLに対してアラートを発出する閾値を設定します。以下は、SuccessのSLIに対するBurn rateを取得するNRQLです。
~~~
FROM Metric SELECT 100 - clamp_max((sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100, 100) AS 'Error rate' WHERE entity.guid = '(SLIのGUID)'
~~~

このクエリに対し、Burn rateを[Set thresholds]画面において設定することで、1時間連続でBurn rateが10を上回った場合にアラートを発出する条件の作成ができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938964/7ac22be7-bea0-92f1-5107-7439f55aadac.png)

この設定の注意点は、NRQLにおいて指定するentity.guidは、アプリケーションのGUIDではなく、SLIのGUIDということです。今回、Terraformを利用し設定を投入してみたのですが、誤ってアプリケーションのGUIDを指定していました。

また、**Fast-burn rateとSlow-burn rateの条件を見比べるとわかるのですが、測定期間が異なります**。これは、仮に同じ測定期間で異なるBurn rateのアラート設定を行った場合、必ずBurn rateが低いものからアラートが上がってしまい、複数のBurn rateを設定する意味がなくなってしまうからです。低いBurn rateのアラートの意味は、軽微な問題が起きており、長い時間かけてError budgetを消費してしまうものを検知するためのものです。そのため、Burn rateが低いほど、測定期間を長くする必要があります。

## おわりに
このように、NewRelicはSLOアラートに関するオプションが充実しており、SLOをメインで利用したシステム運用を簡単に始めることができます。この記事を読まれたエンジニアの皆様は、MetricsやLogsに関するアラートだけでなく、**SLOに関するアラートを利用してみてはいかがでしょうか。**