既存または新規の Datadog モニターに基づいて SLO を構築する場合は、モニターベースのソースを選択します。モニターの詳細については、モニターのドキュメントを参照してください。モニターベースの SLO は、時間ベースのデータストリームで、良い動作と悪い動作の時間を区別するのに役立ちます。良い時間の合計を合計時間の合計で割った値を使用すると、サービスレベル指標（SLI）が得られます。
SLO ステータスページで New SLO + を選択します。その後、Monitor をクリックします。
開始するには、Datadog モニターを使用する必要があります。新しいモニターをセットアップするには、モニター作成ページに移動し、SLO でサポートされているモニターの種類のいずれかを選択します（以下にリストされています）。名前でモニターを検索し、それをクリックしてソースリストに追加します。
たとえば、ユーザーリクエストのレイテンシーが 250 ミリ秒を超えるとアラートを出すように構成されたメトリクスモニターがある場合、そのモニターにモニターベースの SLO を設定できます。過去 30 日間で 99% の SLO ターゲットを選択したとします。これが意味するのは、ユーザーリクエストのレイテンシーは過去 30 日間の 99% の時間で 250 ミリ秒未満でなければならないということです。これを設定するには、次のようにします。
サポートされるモニターの種類:
例: 物理デバイスの稼働時間を追跡している場合を考えます。カスタムメトリクスを使用して、host:foo のメトリクスモニターを既に構成しているとします。また、このモニターは、到達できなくなった場合に、オンコールチームに ping を送信する場合があります。バーンアウトを回避するために、このホストがダウンしている頻度を追跡する必要があります。
SLO ターゲットは、ターゲットパーセンテージとタイムウィンドウで構成されます。モニターベース SLO のターゲットを設定する場合、ターゲットパーセンテージは、SLO の基底のモニターが OK 状態である必要がある時間の部分を指定し、タイムウィンドウは、ターゲットが追跡される必要があるローリング期間を指定します。
例: 時間リクエストの 99% は、過去 7 日間で 300 ミリ秒未満のレイテンシーである必要がある。
SLO がターゲットパーセンテージを上回っている間、SLO のステータスは緑色のフォントで表示されます。ターゲットパーセンテージに違反すると、SLO のステータスは赤色のフォントで表示されます。オプションで、ターゲットパーセンテージより大きい警告パーセンテージを含めて、SLO 違反に近づいていることを示すこともできます。警告パーセンテージに違反している場合 (ただし、ターゲットパーセンテージには違反していない場合)、SLO ステータスは黄色のフォントで表示されます。
注: モニターベースの SLO に指定できる小数の桁数は、タイムウィンドウに応じて異なります。7 日および 30 日目標の場合は小数第 2 位まで、90 日目標の場合は小数第 3 位まで許可されます。SLO の詳細 UI に表示される精度は最大 num_target_decimal_places、つまり 7 日および 30 日目標の場合は小数第 2 位まで、90 日目標の場合は小数第 3 位までです。モニターベースの SLO エラーバジェット時間に基づき指定されるため、このような制限が設けられています。7 日および 30 日目標の 99.999% の結果は、それぞれ 6 秒および 26 秒のエラーバジェットとなります。モニターは毎分評価をするため、モニターベースの SLO の粒度も 1 分です。これは、上記の例では 1 件のアラートは 6 秒および 26 秒のエラーバジェットを完全に消費し過剰利用することを意味します (さらに粒度が必要なユースケースについては、メトリクスベースの SLO を使用することをご検討ください)。さらに、このように小さなエラーバジェットは、実際に達成するには非現実的である場合が多いです。
ここでは、説明および SLO と関連付けたいタグ内に、SLO の目的についてのコンテキスト情報を関連情報またはリソースも含めて追加できます。
全体的なステータスとは、単一のマルチアラートモニターで、すべてのモニターやすべての計算済みグループが OK の状態である時間の割合のことです。モニターを集計した平均値でも、グループを集計した平均値でもありません。
3 台のモニターの次の例を検討してください (これは、単一のマルチアラートモニターに基づくモニターベースの SLO にも適用できます)。
| モニター | t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | t9 | t10 | ステータス |
|---|---|---|---|---|---|---|---|---|---|---|---|
| モニター 1 | OK | OK | OK | OK | アラート | OK | OK | OK | OK | OK | 90% |
| モニター 2 | OK | OK | OK | OK | OK | OK | OK | OK | アラート | OK | 90% |
| モニター 3 | OK | OK | アラート | OK | アラート | OK | OK | OK | OK | OK | 80% |
| 全体的なステータス | OK | OK | アラート | OK | アラート | OK | OK | OK | アラート | OK | 70% |
この場合は、全体的なステータスが個々のステータスの平均よりも低いという結果になります。
場合によっては、1 つのグループ化された Synthetic テストで構成されるモニターベースの SLO のステータス計算に例外があります。Synthetic テストには、テストが ALERT 状態に入るときの動作を変更し、その結果、全体的なアップタイムに影響を与えるオプションの特別なアラート条件があります。
これらの条件のいずれかをデフォルト以外に変更することにより、その 1 つの Synthetic テストのみを使用するモニターベースの SLO の全体的なステータスは、Synthetic テストの個々のグループの集計ステータスよりも優れているように見える可能性があります。
Synthetic テストのアラート条件の詳細については、Synthetic モニタリングドキュメントにアクセスしてください。
メトリクスモニターの種類に基づく SLO には、SLO Replay と呼ばれる機能があり、基底のモニターのメトリクスとクエリコンフィギュレーションから取得された履歴データで SLO ステータスを埋め戻します。つまり、新しいメトリクスモニターを作成し、その新しいモニターに SLO を設定した場合、SLO のステータスがいっぱいになるまで 7、30、または 90 日間待たなくても、SLO Replay がトリガーされ、そのモニターとモニターのクエリの基底のメトリクスを見ることでステータスをより早く取得します。SLO Replay は、基底のメトリクスモニターのクエリが変更された (たとえば、しきい値が変更された) ときにもトリガーされ、新しいモニターコンフィギュレーションに基づいてステータスが修正されます。SLO Replay が SLO のステータス履歴を再計算した結果、モニターの更新後、モニターのステータス履歴と SLO のステータス履歴が一致しない場合があります。
注: SLO Replay は、Synthetic テストまたはサービスチェックに基づく SLO ではサポートされていません。
Datadog は、Alert Recovery Threshold と Warning Recovery Threshold を備えたモニターを使用しないことを推奨します。これらは、SLO 計算にも影響を与え、SLI の良い動作と悪い動作を明確に区別できないためです。
SLO の計算には、モニターが手動で解決される場合、または After x hours automatically resolve this monitor from a triggered state（x 時間後に、このモニターをトリガー状態から自動的に解決する）設定の結果として解決される場合は考慮されません。これらがワークフローにとって重要なツールである場合は、モニターを複製し、自動解決設定と @-notification を削除して、SLO に複製を使用することを検討してください。
ユースケースに適した SLI タイプを使用していることを確認してください。SLO イベントのドキュメントに記載の通り、Datadog は、モニターベースの SLI とメトリクスベースの SLI をサポートしています。
お役に立つドキュメント、リンクや記事:
