SLIとSLOの作成と編集

サービスの成功は、全リクエスト数に対する成功したレスポンスの数の比率です。これは事実上エラー率ですが、予想されるエラーを取り除くなど、フィルタリングすることができます。

Valid events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}'

ここで、 {entityGuid}はサービスのGUIDです。

Bad events fields

FROM TransactionError
WHERE entityGuid = '{entityGuid}' AND error.expected != true

ここで、 {entityGuid}はサービスのGUIDです。

レイテンシーSLIは、有効なリクエストのうち、良好なエクスペリエンスとして設定された閾値よりも速く処理された割合を測定するものです。

継続時間のしきい値を決めるためには、過去数週間のサービスのパフォーマンスを確認し、その結果を現実的で達成可能なベースラインとして使用します。その後、SLIのしきい値を繰り返し検討し、より意欲的なパフォーマンスに合わせていくことができます。

継続時間の条件に適切な値を選択するために、1 つの典型的な方法は、過去 7 日間または 15 日間の回答の 95 パーセンタイルの継続時間を選択することです。 クエリビルダー を使用してこの継続時間のしきい値を見つけ、それを使用して SLI にとって良いイベントと思われるものを決定します。

SELECT percentile(duration, 95) FROM Transaction WHERE entityGuid = '{entityGuid}' since 7 days ago limit max

Valid events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}' AND transactionType = 'Web'

ここで、 {entityGuid}はサービスのGUIDです。

Good events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}' AND transactionType = 'Web' AND duration < {duration}

• ここで、 {entityGuid}はサービスのGUIDです。
• ここで、 {duration}は、クライアントサービスまたはエンドユーザーに優れたエクスペリエンスを提供すると考える応答時間（秒単位）です。

サービスの成功は、全リクエスト数に対する成功したレスポンスの数の比率です。これは事実上エラー率ですが、予想されるエラーを取り除くなど、フィルタリングすることができます。

Valid events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer'))

ここで、 {entityGuid}はサービスのGUIDです。

Bad events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer')) AND otel.status_code = 'ERROR'

ここで、 {entityGuid}はサービスのGUIDです。

レイテンシーSLIは、有効なリクエストのうち、良好なエクスペリエンスとして設定された閾値よりも速く処理された割合を測定するものです。

継続時間のしきい値を決めるためには、過去数週間のサービスのパフォーマンスを確認し、その結果を現実的で達成可能なベースラインとして使用します。その後、SLIのしきい値を繰り返し検討し、より意欲的なパフォーマンスに合わせていくことができます。

継続時間の条件に適切な値を選択するために、1 つの典型的な方法は、過去 7 日間または 15 日間の回答の 95 パーセンタイルの継続時間を選択することです。 クエリビルダー を使用してこの継続時間のしきい値を見つけ、それを使用して SLI にとって良いイベントと思われるものを決定します。

SELECT percentile(duration.ms, 95) FROM Span WHERE entityGuid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer')) SINCE 7 days ago LIMIT MAX

Valid events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer'))

ここで、 {entityGuid}はサービスのGUIDです。

Good events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer')) AND duration.ms < {duration}

• ここで、 {entityGuid}はサービスのGUIDです。
• ここで、 {duration}は、クライアントサービスまたはエンドユーザーに優れたエクスペリエンスを提供すると考える応答時間（秒単位）です。

サービスの成功は、すべてのリクエストの数に対する成功した応答の数の比率です。 これは実質的にエラー率です。

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = '{appName}'

ここで、 {appName}は APM アプリ名です。

Bad events fields

FROM Metric
SELECT sum(getField(apm.service.error.count, count))
WHERE appName = '{appName}' AND getField(`apm.service.error.count`, count) > 0

ここで、 {appName}は APM アプリ名です。

良好なイベントがカスタム メトリックによって報告されると想像してください。 有効なイベント数は同じである可能性があります。

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = '{appName}'

ここで、 {appName}は APM アプリ名です。

そして、今度はカスタム メトリックを使用して良好なイベントを検出します。

Good data

FROM Metric
SELECT sum(getField(newrelic.timeslice.value, count))
WHERE appName = '{appName}' AND metricTimesliceName = 'Custom/CrossClusterQuery/DataAvailability/status/success'

ここで、 {appName}は APM アプリ名です。

ページビューのうち、エラーなく提供された割合のことです。

Valid events fields

FROM PageView
WHERE entityGuid = '{entityGuid}'

ここで、 {entityGuid}はブラウザアプリのGUIDです。

Bad events fields

FROM JavaScriptError
WHERE entityGuid = '{entityGuid}' AND firstErrorInSession IS true

ここで、 {entityGuid}はブラウザアプリのGUIDです。

これは、有効なページビューのうち、ビューポートに表示される最大のコンテンツ要素が、良好なエクスペリエンスに対応すると考えられる閾値よりも速くレンダリングされた割合です。

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND largestContentfulPaint IS NOT NULL

ここで、 {entityGuid}はブラウザアプリのGUIDです。

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND largestContentfulPaint < '{largestContentfulPaint}'

• ここで、 {entityGuid}はブラウザアプリのGUIDです。

• ここで、 {largestContentfulPaint}は、ビューポートに表示される最大のコンテンツ要素をレンダリングする時間（ミリ秒単位）であり、エンドユーザーに優れたエクスペリエンスを提供します。頻繁な標準は4000ミリ秒です。

  ご使用の環境で{largestContentfulPaint}に使用する現実的な数値を決定するための一般的な方法のひとつは、過去7日間または15日間の応答の95パーセンタイル期間を選択することです。クエリビルダーを使用して検索します。

  SELECT percentile(largestContentfulPaint, 95) FROM PageViewTiming WHERE entityGuid = '{entityGuid}' SINCE 7 days ago LIMIT MAX

  コピー

これは、ユーザーが最初にページにアクセスしてから、そのアクセスに対してブラウザが応答するまでの時間が、一定の閾値以下であるページビューの割合です。

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND interactionToNextPaint IS NOT NULL

ここで、 {entityGuid}はブラウザアプリのGUIDです。

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND interactionToNextPaint < {interactionToNextPaint}

• ここで、 {entityGuid}はブラウザアプリのGUIDです。

• ここで、 {interactionToNextPaint}は、エンドユーザーに優れたエクスペリエンスを提供するためにブラウザーが応答する必要がある時間（ミリ秒単位）です。頻繁な標準は300ミリ秒です。

  ご使用の環境で{interactionToNextPaint}に使用する現実的な数値を決定するための一般的な方法のひとつは、過去7日間または15日間の応答の95パーセンタイル期間を選択することです。クエリビルダーを使用して検索します。

  SELECT percentile(interactionToNextPaint, 95) FROM PageViewTiming WHERE entityGuid = '{entityGuid}' SINCE 7 days ago LIMIT MAX FACET deviceType

  コピー

累積レイアウトシフト（CLS）が良好なページビューの割合です。CLSは、ページの寿命期間中に発生した予期せぬレイアウトシフトについて、個々のレイアウトシフトスコアの総和と表現されます。レイアウトシフトは、レンダリングされたフレームから次のフレームへと可視要素の位置が変わるときに発生します。

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND cumulativeLayoutShift IS NOT NULL

ここで、 {entityGuid}はブラウザアプリのGUIDです。

デスクトップとモバイルデバイスのCLSを別々に追跡するために、別々のSLIを作成したい場合は、フィールドの最後にこれらの条項のいずれかを追加してください。

• and deviceType = 'Mobile'
• and deviceType = 'Desktop'

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND cumulativeLayoutShift < {cumulativeLayoutShift}

• ここで、 {entityGuid}はブラウザアプリのGUIDです。

• ここで、 {cumulativeLayoutShift}は事前設定された値です。優れたユーザーエクスペリエンスを提供するには、サイトのCLSスコアが0.1以下になるように努める必要があります。 0.25以上のCLSスコアは、ユーザーエクスペリエンスが低いと見なされます。

  valid eventsクエリを定義した際に、デスクトップとモバイルデバイスのCLSを別々に追跡するために、別々のSLIを作成することにした場合は、フィールドの最後にこの句を追加します。

  • and deviceType = 'Mobile'
  • and deviceType = 'Desktop'

  ご使用の環境で{cumulativeLayoutShift}に選択する現実的な数を決定するための一般的な方法のひとつは、モバイルデバイスとデスクトップデバイスに分割された、過去7日間または15日間のページ読み込みの75パーセンタイルを選択することです。クエリビルダーを使用して検索します。

  SELECT percentile(cumulativeLayoutShift, 95) FROM PageViewTiming WHERE  entityGuid = '{entityGuid}' since 7 days ago limit max facet deviceType

  コピー

成功とは、すべてのチェックの数に対する、成功した合成チェックの数の比率です。

Valid events fields

FROM SyntheticCheck
WHERE entity.guid = '{entityGuid}'

ここで、 {entityGuid} 合成チェックの GUID です。

Good events fields

FROM SyntheticCheck
WHERE entity.guid = '{entityGuid}' AND result='SUCCESS'

ここで、 {entityGuid} 合成チェックの GUID です。

新しい SLI を定義するには、次の 3 つのオプションのいずれかを選択します。

• Entity data

  : 当社のエージェントまたは独自のカスタムイベントからの標準データに基づいて SLI を作成します。 これが最も一般的なオプションです。 これを選択する場合は、使用するエンティティ (APM サービスなど) を選択します。

• Custom data

  : あるいは、カスタム NRDB イベントまたは次元メトリクスに基づいて SLI を作成することもできます。 サービスレベル データを特定のエンティティに関連付けることができない場合、またはサービスレベルをワークロードに直接関連付けたい場合に、このオプションを使用します。

• Metric data

  : Prometheus、OTel、または独自のカスタム ディメンション メトリクスからのデータに基づいています。

この手順では、どのイベントが有効か、良いか、悪いかを判断する SLI クエリを構成します。

SLI を APM サービスやブラウザアプリと関連付けると、New Relic はいくつかの典型的な SLI とそのクエリーを提案します。サービスレベル目標の基準値として最新のデータを使用しますので、その後に SLI と SLO を編集することができます。

異なるタイプのエンティティを使用している場合、ディメンション メトリックをクエリする場合、または New Relic が提供するベースライン値をカスタマイズする場合は、必要に応じて SLI をカスタマイズできます。たとえば、 WHERE句を使用してヘルスチェックを除外できます。各クエリで異なるイベント タイプを使用することもできます。この場合、各有効なイベントが、適切なクエリまたは不適切なクエリの 1 つ以下のイベントにのみ対応していることを確認してください。

データが収集されたアカウントは、SLIが参照しているエンティティのアカウントと一致します。各フィールドの内容については、上記のセクションを参照してください。

右側には最終的なクエリが表示され、下部には過去数日間の有効なイベントと良い/悪いイベントの数のプレビューが表示されます。

以下は、ディメンション メトリクスのパーセンテージ ベースの成功率の例です。これを SLI の有効/良好なイベントに変換してみましょう。

FROM Metric
SELECT percentage(sum(scrooge_do_expire_count), 
WHERE status = 'success') AS 'Success Rate'
WHERE env='production' 
AND status != 'attempt'

有効なクエリの場合、外側のWHERE句をコピーするだけです。

FROM Metric
SELECT sum(scrooge_do_expire_count))
WHERE env='production'
AND status != 'attempt'

良いイベントは、パーセンテージ関数の外側のWHERE句とWHERE句です。

FROM Metric
SELECT sum(scrooge_do_expire_count))
WHERE env='production'
AND status != 'attempt'
AND status = 'success'

現在サポートされている 4 つの集計関数はcount() 、 sum() 、 getField()およびgetCdfCount()です。 Countとsumすべてのイベント タイプで使用できますが、 getFieldとgetCdfCountはMetricから選択した場合にのみ使用できます。

イベント データで count() 関数を使用して、有効/良好/不良イベントの数を数えます。

sum() 関数は、イベント データまたはディメンション メトリックに事前に集計されたカウンターがある場合に役立ちます。パラメータ、つまり合計に使用する属性が必要です。

getField() と getCdfCount() 関数を使用して、分布指標属性がしきい値を下回る、またはしきい値に達する頻度を確認します。どちらの関数にも属性が必要で、getCdfCount() には値を測定するためのしきい値も必要です。

count()を使用した例:

FROM JavaScriptError
SELECT count(*)
WHERE entityGuid = '{entityGuid}' AND firstErrorInSession IS true

sum()を使用した例:

FROM ServerlessSample
SELECT sum(provider.errors.Sum)
WHERE awsAccountId = 'XXX'  And provider LIKE 'LambdaFunction%'

getField() と getCdfCount()を組み合わせた使用例:

FROM Metric
SELECT getField(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, count) as 'Valid'

FROM Metric
SELECT getCdfCount(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, 0.5) as 'Good'

SLI クエリでワイルドカードを使用することもできます。例を次に示します。

FROM ApiGatewaySample
SELECT sum(provider.cache%Count.Sum)
WHERE awsAccountId = 'XXX'

このステップでは、SLI値のプレビューを取得し、このSLIに1つのSLOを追加します。時間枠の長さと目標のパーセンテージを選択するだけです。右のグラフは、設定している目標が実現可能かどうか、または目標を達成できないことが多いかどうかを予測するのに役立ちます。

ローリングタイムウィンドウのSLOがサポートされています。ローリングタイムウィンドウでは、SLOの準拠には過去N日間のデータが考慮されます。毎分、最も古いデータが現在の計算から抜け落ち、新しいデータがそれに取って代わります。

SLIの短い名前を選択してください。これは、SLIが何を測定しているかを認識するのに役立ちます。

SLIにタグを追加して、後でUIでのSLIの検索、フィルタリング、およびグループ化に使用できるようにすることをお勧めします。

組織にとって意味のある任意のタグを設定できます。ドロップダウンは、次のような便利なタグキーを提案します。

• owner：このサービスレベルを所有するチームまたはビジネスユニットであり、SLOターゲットを逃した場合に対応します。

• category： latencyなど、SLIが測定しているものを説明するキーワード。提案されたサービスレベルフローに従うと、New Relicがこのタグを作成し、後で編集することができます。

• environment：サービスレベルが測定している環境であり、それはユースケースにとって意味があります。

• maturity：SLOがどれほど安定しているかを利害関係者に伝えるのに役立ちます。 test 、 commitment 、 aspirationalなどのタグ値を使用することをお勧めします。

• user_journey およびapplication : これらの種類のタグは、ユーザー ジャーニー全体であろうと、特定のアプリケーションだけであろうと、同じユーザー エクスペリエンスに適用される SLI をグループ化するのに役立ちます。

  さらに、ドロップダウンには関連するエンティティタグも表示されるため、それらをSLIにすばやく追加することもできます。

  

  最後に、オプションでそのサービスレベルの説明を追加できます。