はじめに

この記事はNew Relic Advent Calendar 2024 シリーズ4 23日目の記事です。

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

NewRelicにおけるアラート設定

NewRelicでは、アラート条件を利用することにより、取得したMetricsに対して簡単にアラート設定を行うことができます。

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

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

NewRelicにおけるSLO設定

NewRelicではアラートと同じように、各サービスのSLOを設定し、可視化することができます。SLOの詳細については、Googleの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つですね。

NewRelicにおけるSLOアラート設定

SLOアラートとは、SLOに対するエラーバジェットの消費に関するアラートです。SLOアラートの詳細についてはGoogleのThe Site Reliability Workbook - Alerting on SLOsをご覧ください。

NewRelicでは、SLI, SLOを作成した際に、SLOに関するアラート条件がアカウント単位（NewRelicのテナント単位）で作成されます。これは、Error budgetの残りに対してアラートが発出されるものです。

また、個別のSLOアラートについても容易に設定できます。ServiceLevelsの各項目より、以下のような[Create an alert condition]に飛ぶことができます。

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になるかはこちらの[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を上回った場合にアラートを発出する条件の作成ができます。

この設定の注意点は、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に関するアラートを利用してみてはいかがでしょうか。