ベータ版機能
この機能は現在 ベータ版 です。
SLI と SLO のセットを作成すると、New Relic は SLI データの生成を開始します。最初の結果が New Relic One UI に表示されるまでには数分かかります。サービスレベルを検索します。
- 上部のナビバーで、 Service Levels の下にある More メニュー（カスタマイズ可能）。ここでは、エンティティタグでSLIをフィルタリングできます。
- SLIが定義されている エンティティ のプレビューで。UIのいたるところで見ることができます。例えば、エクスプローラーの ナビゲータービュー からエンティティをクリックしてみてください。
- APM サービスで、レポートの項目で。
- APM サービスやブラウザアプリケーションなど、SLI エンティティを含む任意の ワークロードでのことです。SLIを特定のワークロードの下にグループ化したい場合は、必ずAPMサービスまたはブラウザアプリを既存のワークロードに追加するか、 新しいワークロードを作成してください 。
*任意のSLIをクリックすると、SLIカードが表示されます。
SLIが参照するエンティティとSLIの名前を示します。
各行は、SLOの期間を表しています。
- ターゲットとタイムウィンドウ
- SLO期間中のコンプライアンス
- 残りのリクエストは、予算を超過しています。### SLOの状態を確認する [#understand-slo]リクエストベースのSLOは、総リクエスト数に対するグッドレスポンス数の比率として定義されるSLIから決定されます。つまり、リクエストベースのSLOは、その比率がSLO遵守期間の目標を満たしているか、または上回っている場合に達成されます。* SLOの行の背景が緑色になっていれば、その期間はうまくいっています。100%のリクエストに成功しなかったかもしれませんが、まだ消費できるエラー予算が残っています。
SLOの行の背景が黄色になっている場合は、エラー予算が完全に消費された状態に近いので、残りの期間はより慎重になる必要があります。
SLOの行の背景が赤くなっている場合は、この期間に目標SLOに到達しておらず、エラー予算をすべて消費していることになります。展開する必要がある場合は注意し、SLIを改善するための作業を計画してください。SLOをクリックすると、ゴールデンメトリクス、最新のデプロイメント、異常、進行中の問題など、エンティティに関する詳細なデータを見ることができます。このデータは、いつ、なぜSLOの目標を達成できなかったかを理解するのに役立ちます。同じSLIに複数のSLOを定義することで、エラーバジェットの消費速度を確認することができます。たとえば、1週間全体で0,1%のリクエストのエラーバジェットがある場合、1日でそのほとんどを消費してしまうと、その週の残りの期間、SLOが危険にさらされることになるので、避けたい場合があります。## サービスレベルの詳細を理解する [#sl-details]SLIの詳細は、主に2つの目的で提供しています。* SLO分析のために。どの時間帯でSLOの目標が達成できなかったかを確認する。
SLI/SLOの設定や微調整に。New Relic が SLO 値をどのように算出したかをご覧ください。SLIカードには以下のチャートが含まれています。### 良い反応と悪い反応 [#good-bad]これらは、サービスレベルを分析するための 重要な概念です 。* 有効なリクエストとは、SLIにとって意味のあるものとしてカウントしたいリクエストのことです。
良い反応とは、良い体験を提供すると考えられる反応のことです（例えば、サービスが2秒以内に反応し、エンドユーザーに良いナビゲーション体験を提供した場合など）。
バッドレスポンスとは、悪い体験を提供すると考えられるレスポンスのことです（サービスがサーバーエラーで応答し、ユーザーのフローを中断させたような）。このグラフは、お客様のサービスが受け取った有効なリクエストの総数を、良いものと悪いものに分けて表示しています。このグラフは、お客様のサービスの実際のスループットを示しており、スループットの増加と悪い反応の間に相関関係があるかどうかを確認するのに利用できます。### SLI達成度の推移(%) [#sli-over-time]これは、時間の経過とともに、良いと思われる応答の割合を示すものです。このラインは100％に近い値を示し、ほとんどのリクエストが正常に処理されたことを意味します。### 期間中のコンプライアンス [#compliance-time]これは、SLO遵守期間中に測定された、総イベント（リクエスト）に対する良好なイベント（レスポンス）の比率です。100%に近ければ近いほど、その期間中にSLOの目標を達成していることになります。この割合がSLOの目標値を下回ると、グラフが赤に変わります。信頼性にもっと力を入れる必要があります。### 誤差予算の残額（Requests） [#remaining-budget]エラーバジェットは、SLOの別の読み方です。これは、SLOの期間中に、目的を損なうことなく、どのくらいの割合のリクエストに悪い反応があるかを示すものです。許容される不良反応の総量はリクエストのスループットによって変わるため、New Relic ではエラーバジェットの残りの割合を表示しています。* 残りのエラーバジェットが25％以上であれば、グリーンが表示され、SLOは良好です。
誤差予算が25％以下になると、黄色に変わります。これは、その期間の予算をすべて使い切ってしまうのに近いことを意味します。新しいデプロイメントや変更にはより注意を払い、信頼性向上のための作業を計画するとよいでしょう。
エラー予算が完全に使われると、赤で表示されます。### SLI達成度の経年変化とSLO目標値(%) [#sli-attainment]最後のグラフは、（SLI attainment over time）[#sli-over-time]とSLO目標値の2つの時系列を示しています。SLIの値がSLOの目標値を下回っている場合、そのサービスはSLOに達していないことになります。このチャートを使って、どの時間帯にSLO目標を達成できなかったのかを知ることができます。## 悪い反応を分析する [#analyze-bad]SLO が準拠しない場合、元のデータを分析し、何が問題だったのかに特に重点を置いて、それが顧客にどのような影響を与えるかをよりよく理解したいと思うでしょう。これを行うには、どのサービスレベルでも利用可能な Analyze オプションを使用します。
Analyze をクリックして query builder を開き、データを掘り下げて、SLOの欠落の原因と影響をより深く理解することができます。まず、オリジナルの NRDB バッドイベント、つまり SLO の遵守を損なったイベントを表すクエリから開始します。次に、 FACET節を使用して、特定の属性（アカウント、クライアント ID、要求元など）を分析し、それが特に SLO に損害を与えるかどうかを検出することをお勧めします。このような損害を与える値を、"デトラクタ（detractors）" と呼ぶことにします。例えば、 トランザクション データについて、名前でファセットし、そのサービスのトランザクションが他よりも失敗した結果を返しているかどうかを確認します。どのクライアントが最も多くの失敗した結果を得ているかを知るには、request.uriでファセットしてみる。ブラウザPageViewTimingイベントについては、deviceType,userAgentName,userAgentOSまたはcountryCodeでファセットを試みることができます。
一人またはごく少数の違反者がSLOのコンプライアンスを本当に悪化させていることを察知した場合、いくつかの行動を取ることができます。* まず、問題のトラブルシューティングを行い、減点対象者がSLOを満たすように作業を計画する。また、SLOターゲットをより現実的な値に一時的に調整し、信頼性を向上させるための作業を計画することも可能です。しかし、もしその減点対象が本当に例外で、サービスのパフォーマンスや信頼性に対する一般的な期待に容易に合致しないのであれば、その場合のために専用のSLOを用意することを検討してください。このような手順をお勧めします。* まず、元の SLI クエリに
WHERE句を使用して、デタッチャをフィルタリングします（例えば、WHERE countryCode != 'US')。次に、クエリに
WHERE句を設け、デトラクターケースのみを考慮した新しい SLI を作成し（例えば、WHERE countryCode = 'US'）、より現実的な SLO ターゲットを設定する。**