NewRelicUI を使用してSLIとSLOを手動で作成できます。または、 NerdGraphAPI とTerraformServiceLevelリソース を使用してプロセスを自動化することもできます。
要件 events-to-metricsを変更および削除する機能 が必要です。
SLIおよびSLOを作成するための重要な概念 SLIとSLOを定義する際には、これらの概念に留意してください。
関連するエンティティ New Relicエコシステムでは、すべてのサービスレベルが別のエンティティ にリンクされています。これは、スタック内でデータを報告する要素、またはアクセス可能なデータを生成する要素です。サービスレベルが関連するエンティティによって、SLI/SLOの結果が表示される場所が決まります。
SLI は、New Relic に報告される NRDB イベントであればどのようなものでも定義できるため、カスタムイベントをベースにすることもできます。ほとんどのカスタムイベントは、単一の New Relic エンティティに関連するものではなく、より高度なビジネスやユーザーエクスペリエンスのインサイトを提供するものです。この場合でも、SLIを特定のエンティティやワークロードに関連付けることができます。
SLIクエリ SLIは、有効なリクエストの総数のうち、良いレスポンスの割合として定義されます。ほとんどの場合、有効な作品と良い作品を定義することでSLIを設定します。
有効なリクエスト は、SLIにとって意味のあるものとしてカウントしたいあらゆるリクエストです(例えば、ヘルスチェックによって開始されたものではないエンドポイントに関連するすべてのトランザクションなど)。良好なレスポンス は、エンドユーザーやクライアントサービスに良好な出力を提供していると考えられるあらゆるレスポンスです(例えば、サービスが2秒以内に応答し、エンドユーザーに良好なナビゲーション体験を提供した場合など)。代わりに、悪い反応と思われるものを定義することもできます。
不正な応答 とは、不正な出力を提供すると見なされる応答のことです(たとえば、サービスがサーバーエラーで応答したため、クライアントがフローに失敗しました)。 New Relicは、適切な応答の数をvalid - bad
として自動的に導き出します。リクエストベースのSLOは、リクエストの総数に対する適切なリクエストの数の比率として定義されるSLIに基づいています。要求ベースのSLOは、その比率がコンプライアンス期間の目標を満たしているか超えている場合に満たされます。
推奨されるSLI このセクションでは、サービスやブラウザアプリケーションのパフォーマンスを測定するために一般的に使用されるいくつかのSLIを紹介します。
New Relic エージェントを搭載した APM サービスの SLI Transaction
イベントに基づくと、これらのSLIはリクエストドリブンサービスで最も一般的です。
サービスの成功 サービスの成功は、全リクエスト数に対する成功したレスポンスの数の比率です。これは事実上エラー率ですが、予想されるエラーを取り除くなど、フィルタリングすることができます。
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}'
ここで、 {entityGuid}
はサービスのGUIDです。
悪いイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND error.expected IS FALSE
ここで、 {entityGuid}
はサービスのGUIDです。
サービスの待ち時間 レイテンシーSLIは、有効なリクエストのうち、良好なエクスペリエンスとして設定された閾値よりも速く処理された割合を測定するものです。
継続時間のしきい値を決めるためには、過去数週間のサービスのパフォーマンスを確認し、その結果を現実的で達成可能なベースラインとして使用します。その後、SLIのしきい値を繰り返し検討し、より意欲的なパフォーマンスに合わせていくことができます。
継続時間の条件に適切な値を選択するために、1 つの典型的な方法は、過去 7 日間または 15 日間の回答の 95 パーセンタイルの継続時間を選択することです。 クエリビルダー を使用してこの継続時間のしきい値を見つけ、それを使用して SLI にとって良いイベントと思われるものを決定します。
select percentile(duration, 95) from Transaction where entityGuid = '{entityGuid}' since 7 days ago limit max
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND transactionType = 'Web'
ここで、 {entityGuid}
はサービスのGUIDです。
良いイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND transactionType = 'Web' AND duration < {duration}
ここで、 {entityGuid}
はサービスのGUIDです。 ここで、 {duration}
は、クライアントサービスまたはエンドユーザーに優れたエクスペリエンスを提供すると考える応答時間(秒単位)です。 OpenTelemetryで計測されたAPMサービスのSLI OpenTelemetryのスパンに基づくと、これらのSLIはリクエストドリブンのサービスで最も一般的なものです。
サービスの成功 サービスの成功は、全リクエスト数に対する成功したレスポンスの数の比率です。これは事実上エラー率ですが、予想されるエラーを取り除くなど、フィルタリングすることができます。
有効なイベントフィールド
WHERE: entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer'))
ここで、 {entityGuid}
はサービスのGUIDです。
悪いイベントフィールド
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
有効なイベントフィールド
WHERE: entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer'))
ここで、 {entityGuid}
はサービスのGUIDです。
良いイベントフィールド
WHERE: entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer')) AND duration.ms < {duration}
ここで、 {entityGuid}
はサービスのGUIDです。 ここで、 {duration}
は、クライアントサービスまたはエンドユーザーに優れたエクスペリエンスを提供すると考える応答時間(秒単位)です。 ブラウザアプリケーション用SLI 以下のSLIは、GoogleのBrowser Core Web Vitalsに基づいています。
ブラウザーアプリの成功 ページビューのうち、エラーなく提供された割合のことです。
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}'
ここで、 {entityGuid}
はサービスのGUIDです。
悪いイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND firstErrorInSession IS true
ここで、 {entityGuid}
はブラウザアプリのGUIDです。
ブラウザアプリ最大のcontentful paint これは、有効なページビューのうち、ビューポートに表示される最大のコンテンツ要素が、良好なエクスペリエンスに対応すると考えられる閾値よりも速くレンダリングされた割合です。
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND largestContentfulPaint IS NOT NULL
ここで、 {entityGuid}
はサービスのGUIDです。
良いイベントフィールド
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
ブラウザアプリの初回入力遅延 これは、ユーザーが最初にページにアクセスしてから、そのアクセスに対してブラウザが応答するまでの時間が、一定の閾値以下であるページビューの割合です。
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND firstInputDelay IS NOT NULL
ここで、 {entityGuid}
はサービスのGUIDです。
良いイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND firstInputDelay < {firstInputDelay}
ここで、 {entityGuid}
はブラウザアプリのGUIDです。
ここで、 {firstInputDelay}
は、エンドユーザーに優れたエクスペリエンスを提供するためにブラウザーが応答する必要がある時間(ミリ秒単位)です。頻繁な標準は300ミリ秒です。
ご使用の環境で{firstInputDelay}
に使用する現実的な数値を決定するための一般的な方法のひとつは、過去7日間または15日間の応答の95パーセンタイル期間を選択することです。クエリビルダーを使用して検索します。
SELECT percentile(firstInputDelay, 95) FROM PageViewTiming WHERE entityGuid = '{entityGuid}' since 7 days ago limit max facet deviceType
ブラウザアプリの累積レイアウト変更 累積レイアウトシフト(CLS)が良好なページビューの割合です。CLSは、ページの寿命期間中に発生した予期せぬレイアウトシフトについて、個々のレイアウトシフトスコアの総和と表現されます。レイアウトシフトは、レンダリングされたフレームから次のフレームへと可視要素の位置が変わるときに発生します。
有効なイベントフィールド
WHERE: entityGuid = '{entityGuid}' AND cumulativeLayoutShift IS NOT NULL
ここで、 {entityGuid}
はサービスのGUIDです。
デスクトップとモバイルデバイスのCLSを別々に追跡するために、別々のSLIを作成したい場合は、フィールドの最後にこれらの条項のいずれかを追加してください。
and deviceType = 'Mobile'
and deviceType = 'Desktop'
良いイベントフィールド
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
サービスレベルの作成と編集 UIの いくつかの場所からSLIとSLOを作成できます。
トップメニューのサービスレベル ビューから。 SLIは、ワークロードを含む、アカウント全体の任意のエンティティに関連付けることができます。 任意のAPMサービスの Service levels ページから。SLI は、その特定の APM サービスに関連付けられます。この出発点を使用した場合、New Relic は最新の利用可能なデータに基づいて、このエンティティタイプの最も一般的なサービスレベル指標を自動的に作成します。 任意のワークロードの サービスレベル タブから。SLI をワークロード内の任意のエンティティ、またはワークロード自体に関連付けることができます。 以下の手順に従ってください。
SLIデータソースの選択 新しいSLIを定義するために、以下の2つのオプションのいずれかを選択します。
エンティティデータ :エージェントからの標準データに基づいてSLIを作成します。これは最も一般的なオプションです。これを選択する場合は、使用するエンティティ(APMサービスなど)を選択します。カスタムデータ : 別の方法として、カスタムNRDBイベントに基づいてSLIを作成することもできます。このオプションは、サービスレベルデータを特定のエンティティに関連付けることができない場合や、サービスレベルをワークロードに直接関連付ける場合に使用します。このステップでは、どのイベントが有効なのか、良いのか、悪いのかを判断するSLIカウントクエリを設定します。
SLI を APM サービスやブラウザアプリと関連付けると、New Relic はいくつかの典型的な SLI とそのクエリーを提案します。サービスレベル目標の基準値として最新のデータを使用しますので、その後に SLI と SLO を編集することができます。
別のタイプのエンティティを使用している場合、またはNew Relicが提供するベースライン値をカスタマイズしたい場合は、必要に応じてSLIをカスタマイズできます。たとえば、 WHERE
句を使用してヘルスチェックを除外できます。クエリごとに異なるイベントタイプを使用することもできます。この場合、有効な各イベントが、良いクエリまたは悪いクエリの1つ以下のイベントにのみ対応していることを確認してください。
データが収集されたアカウントは、SLIが参照しているエンティティのアカウントと一致します。各フィールドの内容については、上記のセクションを参照してください。
右側には最終的なクエリが表示され、下部には直近の有効なイベントや良い/悪いイベントのカウントのプレビューが表示されます。
重要 SLIのクエリは、NRDBのイベントとスパンをサポートしていますが、次元メトリクスはまだサポートしていません。
SLOのタイムウィンドウとターゲットの設定 このステップでは、SLI値のプレビューを取得し、このSLIに1つのSLOを追加します。時間枠の長さと目標のパーセンテージを選択するだけです。右のグラフは、設定している目標が実現可能かどうか、または目標を達成できないことが多いかどうかを予測するのに役立ちます。
ローリングタイムウィンドウのSLOがサポートされています。ローリングタイムウィンドウでは、SLOの準拠には過去N日間のデータが考慮されます。毎分、最も古いデータが現在の計算から抜け落ち、新しいデータがそれに取って代わります。
SLIに名前を付けてタグを付ける SLIの短い名前を選択してください。これは、SLIが何を測定しているかを認識するのに役立ちます。
SLIにタグを追加して、後でUIでのSLIの検索、フィルタリング、およびグループ化に使用できるようにすることをお勧めします。
組織にとって意味のある任意のタグを設定できます。ドロップダウンは、次のような便利なタグキーを提案します。
owner
:このサービスレベルを所有するチームまたはビジネスユニットであり、SLOターゲットを逃した場合に対応します。
category
: latency
など、SLIが測定しているものを説明するキーワード。提案されたサービスレベルフローに従うと、New Relicがこのタグを作成し、後で編集することができます。
environment
:サービスレベルが測定している環境であり、それはユースケースにとって意味があります。
maturity
:SLOがどれほど安定しているかを利害関係者に伝えるのに役立ちます。 test
、 commitment
、 aspirational
などのタグ値を使用することをお勧めします。
user_journey
およびapplication
:これらの種類のタグは、ユーザージャーニー全体であろうと、特定のアプリケーションだけであろうと、同じユーザーエクスペリエンスに適用されるSLIをグループ化するのに役立ちます。
さらに、ドロップダウンには関連するエンティティタグも表示されるため、それらをSLIにすばやく追加することもできます。
最後に、オプションでそのサービスレベルの説明を追加できます。
SLIの編集 SLIを作成したら、UIにアクセスし、[ ... ]メニューをクリックして編集します。