NewRelicUI を使用してSLIとSLOを手動で作成できます。または、 NerdGraphAPI とTerraformServiceLevelリソース を使用してプロセスを自動化することもできます。
要件と制限 サービス レベルを作成および管理するには、 events-to-metrics を変更および削除する機能 が必要です。
複数のアカウント を持つ New Relic 組織の場合: サービス レベルは 1 つのアカウントにのみ関連付けることができます。複数のアカウントにまたがるエンティティを持つワークロードのサービス レベルを作成しようとしている場合は、関連付けられているすべてのエンティティが同じアカウントに含まれるように、ワークロードを再構築する必要がある場合があります。
SLIおよびSLOを作成するための重要な概念 SLIとSLOを定義する際には、これらの概念に留意してください。
関連するエンティティ New Relicエコシステムでは、すべてのサービスレベルが別のエンティティ にリンクされています。これは、スタック内でデータを報告する要素、またはアクセス可能なデータを生成する要素です。サービスレベルが関連するエンティティによって、SLI/SLOの結果が表示される場所が決まります。
New Relic に報告される任意の NRDB イベントまたはディメンション メトリックで SLI を定義できます。ほとんどのカスタム イベントは、単一の 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 を作成できます。
one.newrelic.com > サービス レベル に移動します。SLI は、ワークロードを含め、アカウント全体の任意のエンティティに関連付けることができます。任意の APM サービス、ブラウザ アプリケーション、または Synthetic モニターの [サービス レベル] ページから。SLI は、その特定のエンティティに関連付けられます。この開始点を使用すると、New Relic は、利用可能な最新のデータに基づいて、このエンティティ タイプの最も一般的なサービス レベル インジケーターを自動的に作成します。 任意のワークロードの [サービス レベル ] タブから。SLI は、ワークロード内の任意のエンティティまたはワークロード全体に関連付けることができます。 サービス レベルは 1 つのアカウントにのみ関連付けることができることに注意してください。詳細については、要件 を参照してください。
サービス レベルを作成するには、次の手順に従います。
SLIデータソースの選択 新しいSLIを定義するために、以下の2つのオプションのいずれかを選択します。
エンティティ データ : SLI は、エージェントからの標準データまたは独自のカスタム イベントに基づいています。これは最も一般的なオプションです。これを選択する場合は、使用するエンティティ (APM サービスなど) を選択します。カスタム データ : または、カスタム NRDB イベントまたはディメンション メトリックに基づいて SLI を作成することもできます。サービス レベル データを特定のエンティティに関連付けることができない場合、またはサービス レベルをワークロードに直接関連付ける場合は、このオプションを使用します。メトリック データ : Prometheus、OTel、または独自のカスタム ディメンション メトリックからのデータに基づきます。この手順では、どのイベントが有効か、良いか、悪いかを判断する SLI クエリを構成します。
SLI を APM サービスやブラウザアプリと関連付けると、New Relic はいくつかの典型的な SLI とそのクエリーを提案します。サービスレベル目標の基準値として最新のデータを使用しますので、その後に SLI と SLO を編集することができます。
異なるタイプのエンティティを使用している場合、ディメンション メトリックをクエリする場合、または New Relic が提供するベースライン値をカスタマイズする場合は、必要に応じて SLI をカスタマイズできます。たとえば、 WHERE
句を使用してヘルスチェックを除外できます。各クエリで異なるイベント タイプを使用することもできます。この場合、各有効なイベントが、適切なクエリまたは不適切なクエリの 1 つ以下のイベントにのみ対応していることを確認してください。
データが収集されたアカウントは、SLIが参照しているエンティティのアカウントと一致します。各フィールドの内容については、上記のセクションを参照してください。
右側には最終的なクエリが表示され、下部には過去数日間の有効なイベントと良い/悪いイベントの数のプレビューが表示されます。
重要 現時点では、 count()
とsum()
の 2 つの集計関数がサポートされています。詳細については、 FAQ ページをご覧ください。
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 を作成したら、次に示すように、[ ... ] メニューをクリックしてから [ Edit
] をクリックすることにより、サービス レベル リスト ページから編集できます。
または、 Edit
をクリックして、概要ページから同じことを行うことができます。
SLM を最適化する SLM 実装を最適化する方法については、 可観測性成熟度 SLM ガイド を参照してください。