New Relic サービスレベル管理のセカンドステップ (前編)

SLI/SLO 設定例

SLI/SLO の作成例を簡単に紹介します。ここではすでに存在する Synthetic Monitoring の Ping モニター (ポーリング間隔 1分、1ロケーション、名前: My URL sample) に関する SLI を設定例として作成します。

プラットフォーム UI > Service Levels ページから 右上の「Add a service level」 にて、新規作成します。

1. Set SLI: Choose data ステップ

ターゲットエンティティを選択します。ここでは Syntheic Monitor の My URL sample を探して選択します。

Entity Type = Syntheitc monitor や文字列フィルターを利用すると検索が容易になります。

2. Set SLI: Configure queries ステップ

次に評価基準用のクエリを設定します。

Success を選択後に Customize SLI を選択すれば、デフォルト条件を編集できます。カスタマイズを辞めたい場合は、Switch to SLI presets にて戻すことができます。

ここでは デフォルト Good 条件の 「応答が成功」に「応答時間 2.4秒以内」という条件を追加します。 編集画面のクエリチャートで Valid (すべての試行) と Good (SLI 条件を満たす試行) に多少のズレができ、すべての試行が Good ではなくなっています。

3. Set SLO: Time window and target percentage ステップ

次に SLO 設定で、期間とターゲット(基準値)を設定します。

評価期間は 1 day, 7 days, 28 days から選択でき、ターゲットは 0 ~ 100% の数字を 0.00001 刻みで設定可能です。

ここでは 説明の都合上期間を 7日、ターゲットを 98.5% とします。

4. Name, tag and describe this service level ステップ

最後に作成した Service Level に名前と説明を設定します。また、タグを設定することも可能です。

ここに設定されるタグは、このサービスレベルに対して、付与されるタグです、元となった Synthetic モニターに設定されるわけではありません。

アプリヘッダー部分

まずは左上部のアプリヘッダー部分 (緑点線枠) です。 上段に、グレーのエンティティアイコン、サービスレベルの名前、お気に入りボタン、Tags、Metadata、Workloads と並び、 下段に User experience および Engineering operations と関連マップコンテンツ要素が表示されます。

エンティティアイコンは、UI の共通表示項目で、エンティティのヘルスステータスを意味します。 グレーはアラートが未設定であることを意味します。緑は、設定されているアラートに関連するインシデントなし、黄色は警告インシデント、赤はクリティカルインシデントがあることを示しています。 ref. エンティティのヘルスステータス

Tags には、作成時に追加したタグ、SLO の期間やターゲット値などのデフォルトタグが記載されます。 注目点としては、nr.associatedEntityGuid の項目で、この GUID は 関連対象の GUID で、ここでは Synthetic Monitor の Ping モニター (My URL sample) の GUID となります。

一方で、Metadata に記載される Entity guid は、このサービスレベルに割り振られた GUID が表示されます。

関連マップコンテンツ要素の User experience と Engineering operations は、(Summary の 2つ下の) Map にリンクされます。

User experience の Good 表示は、User experience に属するエンティティでインシデントが発生していないことを意味しており 同様に Engineering operations の Good 表示は、Engineering operations に属するエンティティでインシデントが発生していないことを意味します。

この例では、User experience のエンティティは Synthetic Monitor の Ping モニター (My URL sample) になっているので、Synthetic Monitor に関して設定されたアラートインシデントが発生した場合、表示が変わります。

Engineering operations のエンティティは、このサービスレベルとなっているので、このサービスレベルに関連するアラートインシデントが発生した場合 Good ではなくなります。

Map ではエンティティを関連性 (is called by や hosts など) とともに追加することもできます。 下記は左が初期、右図が障害中のエンティティと Workload を追加した場合の例です。

次は右上部のアプリヘッダー部分 (紫点線枠) で タイムピッカー、編集ボタン、アクションコントロールボタン、ダッシュボード追加ボタンがあります。

本ページにおいて、タイムピッカーを変更すると、下図の SLI compliance (ビルボードおよび時系列グラフ) および Error budget と Good/Bad 時系列グラフの期間が変わります。

編集ボタンで、先ほど作成した SLI/SLO の値を変更することができます。

アクションコントロールボタンでは、Create an alert、Analyze、Delete 処理を行うことができます。

Add to Dashboard では、下部の４つのウィジェットをもつダッシュボードを作成することができます。

関連ウィジェット

中央には、4つのウィジェット (2つのビルボードと 2つの時系列グラフ) が表示されますが 作成直後には No value やグラフデータが表示されていません、数分後に再アクセスすると値が表示されるようになります。

作成時の編集画面では類似の Valid/Good (Bad) および SLO 消費率 の時系列グラフが表示されていましたが、 作成後は、このサービスレベル用のデータが、別途作成されるようになります。そのため、作成直後はまだデータがないため、No data と表示されます。 また、いつまでも No data の表示が続く場合は、関連エンティティのデータ (ここでは Synthetic モニターの実行) が行われているか、または設定内容の確認を実施ください。

編集画面では、過去データの SyntheticCheck イベントを用いて描画されたグラフですが、Summary 画面の表示内容は 別途作成される Metric データから描画されます。

サービスレベル用に作成されたデータは 1分単位で集計されたメトリックデータとして、記録され、それぞれ下記の metricName をクエリすることで確認することができます。

• newrelic.sli.valid (Valid イベント)
• newrelic.sli.good (Good レスポンス (SLI で good を選択した場合))
• newrelic.sli.bad (Bad レスポンス (SLI で bad を選択した場合))

サービスレベル作成後にそれほど時間が経っていない場合に 7日や28日期間で表示しても、まだデータは溜まっていないため、編集時に表示された内容とは異なった値が表示されるかと思います。繰り返しとなりますがサービスレベル作成後 ~ 現在までのデータしか存在しないためです。

また、作成される sli データは、Valid または Good (Bad) イベントが発生しないと作成されません。

本サービスレベルの対象は 1 分ポーリングで実行される Synthetic モニターであるため、Valid イベントはおよそ 1分に 1回発生していることになります。 そのため 1分ごとに集計される Metric.newrelic.sli.valid は count: 1 で記録されます。もし 1分に N回実行されるモニターである場合は、count: N と記録されます。 また、実行が 5分に 1回だった場合、実行された時間を含む newrelic.sli.valid のみが作成されます。つまり 1分集計のメトリクスデータは 5分に 1度しか作成されません。

newrelic.sli.good も同様で、Good な条件を満たす場合、データが作成されます。 Good 条件を満たさない (モニターが失敗または応答時間が 2.4秒以上かかる) 場合は newrelic.sli.good にはカウントされません。また、1分間に Good データがない場合は、その時間の newrelic.sli.good データは作成されません。

次にそれぞれのウィジェットの詳細を確認します。 プリセットウィジェットは、ドロップダウンメニューの View query にてクエリの詳細を確認することができます。

Good レスポンスのプリセットウィジェットの Query 内容

SLO compliance (%) (Good version)

View Query で表示される NRQL は下記です。

FROM Metric SELECT clamp_max(sum(newrelic.sli.good) / sum(newrelic.sli.valid) * 100, 100) as 'SLO compliance (%)'
WHERE entity.guid = 'MzgzNDY4N3xFWFR8U0VSVklDRV9MRVZFTHw1ODYwMDI'

clamp_max 関数を除くと少し見やすくなり、単純に Good イベント/全イベントの割合であることに気がつきます。 SLI の達成率という方ががわかりやすいかもしれません。

SELECT sum(newrelic.sli.good) / sum(newrelic.sli.valid) * 100 as 'SLO compliance (%)'
FROM Metric
WHERE entity.guid = 'この SLI GUID'

Metric をイベントソースとしており、このサービスレベルが作成されたあとに作られた newrelic.sli.valid および newrelic.sli.good (bad) を用いています。 NRQL の集計期間 (SINCE/UNTIL) の明示的な記載はありませんが、time picker にて指定された時間で行われます。

clamp_max 関数 またはこのあと登場する clamp_min 関数 は、N 以上 (または N 以下) の値の場合は、すべて N を返すという役割の関数です。 Valid や Good (Bad) の条件は任意入力可能なため、100% や 0% 以下の値になってしまう可能性があります。そのような値の場合は、意味のない値であるため、この関数にて 0 ~ 100 % の範囲になるようにされます。

SLI attainment over time (%) (Good version)

同様に clamp_max 関数 を省くと下記の形で、Good イベントの割合に関する時系列グラフです。

SELECT sum(newrelic.sli.good) / sum(newrelic.sli.valid) * 100 AS 'SLO compliance', 98.5 as 'SLO target'
FROM Metric WHERE entity.guid = 'この SLI GUID'
UNTIL 2 minutes AGO TIMESERIES AUTO

TIMESERIES は AUTO なので、表示期間によってプロット幅は変化します。プロット幅ごとの期間での達成率を描画したものとなります。

Remaining error budget (%) (Good version)

次にエラーバジェットですが、これは "残りエラーバジェット率" に対応します。

同じように clamp_max/min 関数 を除くと下記のような NRQL で計算されます。

SELECT (sum(newrelic.sli.good) / sum(newrelic.sli.valid) * 100 - 98.5) / (100 - 98.5) * 100 as 'Remaining error budget (%)'
FROM Metric WHERE entity.guid = 'この SLI GUID'

分子は 指摘期間の Good 率 (SLI 達成率) から SLO目標 (98.5) を引いた値なので、指定した期間での残りのエラーバジェットに該当します。

分母は 100 から SLO目標 (98.5) を引いた値 なので、初期のエラーバジェット になります。

よって、残りのエラーバジェット/初期エラーバジェット*100 で、残りエラーバジェット率 を計算したものとなります。

Good and bad events (Good version)

最後は Good and bad events ですが、単純な Good イベントと Bad イベント (全イベント - Good イベント) の時系列グラフです。

SELECT sum(newrelic.sli.good) AS 'Good', sum(newrelic.sli.valid) - sum(newrelic.sli.good) AS 'Bad'
FROM Metric WHERE entity.guid = 'この SLI GUID'
UNTIL 2 minutes AGO TIMESERIES AUTO

Bad レスポンスのプリセットウィジェットの Query 内容

SLI 作成時に Good response ではなく、Bad response を選択した場合の各ウィジェットの NRQL についても紹介します。 しかし、Good イベント = Valid (全) イベント - Bad イベント に置き換えられるだけなので、特に解説は不要と思います。

SLO compliance (%) (Bad version)

SELECT (sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100 as 'SLO compliance (%)'
FROM Metric WHERE entity.guid = 'この SLI GUID'

SLI attainment over time (%) (Bad version)

SELECT (sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100 AS 'SLO compliance', 98.5 as 'SLO target'
FROM Metric WHERE entity.guid = 'この SLI GUID'
UNTIL 2 minutes AGO TIMESERIES AUTO

98.5 は SLO目標値です

Remaining error budget (%) (Bad version)

SELECT ( (sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100 ) - 98.5, 0 / (100 - 98.5)) * 100 as 'Remaining error budget (%)'
FROM Metric WHERE entity.guid = 'この SLI GUID'

98.5 は SLO目標値です

Good and bad events (Bad version)

SELECT sum(newrelic.sli.valid) - sum(newrelic.sli.bad) AS 'Good', sum(newrelic.sli.bad) AS 'Bad'
FROM Metric WHERE entity.guid = 'この SLI GUID' UNTIL 2 minutes AGO TIMESERIES AUTO

SLI/SLO を編集した場合の挙動

作成後に SLI 条件や SLO ターゲット (目標値) を変更した場合、変更後のイベント (newrelic.sli.valid または newrelic.sli.good, bad) は変更後の設定内容で算出されるようになります。しかし、当然ながら過去の算出値は変化しません。

Metric を確認すると変更時刻 (sli.updatedAt) が変わっていることが確認できますが sli.id や sli.guid は変更されません。

ここまで、サービスレベルの各データは 作成後から生成される newrelic.sli.valid または newrelic.sli.good, bad を元に算出されていることを見てきましたが、 関連値を算出する NRQL には、変更時刻 などは含まれていませんでした。

これは少し丁寧に理解する必要がありますが、評価式では変更後の SLO 設定値と それまでの SLI 条件で評価された newrelic.sli.valid および newrelic.sli.good (bad) イベントの数を利用して、現在の値を算出します。

例えば、3日前に SLI 条件を変更したとしましょう。

7日前までの期間で表示される SLO compliance データは、

7~4日前のデータは古い SLI 条件の newrelic.sli.{valid,good,bad} で算出されたもので

変更後の直近 3日間のデータは 新しい条件で算出されたデータが利用されることになります。

同じ例で 3日前に SLO 目標値を変更したとしましょう。

利用される newrelic.sli.{valid,good,bad} は上記と同じですが、計算式内で利用される SLO目標は、変更後の SLO 目標値で計算されることになります。

SELECT (sum(newrelic.sli.good) / sum(newrelic.sli.valid) * 100 - 現在設定されているSLI目標) / (100 - 現在設定されているSLI目標) * 100 as 'Remaining error budget (%)'
FROM Metric WHERE entity.guid = 'この SLI GUID'

変更後を行った場合、算出式自体には変化は、ありませんが Valid, Good, Bad イベントはそのイベントが発生した際の SLI 条件で評価されたイベントとなります。 本点を考慮いただき、データを解釈いただければと思います。

後編ではアラート設定に関する記載しております、アラートの内容に関してご興味ございましたらご確認ください。