はじめに

1. SLO Manage ページ に移動します。

2. ユーザーの目線から考えてみてください:

   • ユーザーはアプリケーションをどのように操作していますか？
   • アプリケーションを通じたユーザージャーニーはどのようなものですか？
   • それらのジャーニーには、インフラストラクチャーのどの部分が関わっていますか？
   • システムから何を期待していますか？何を達成したいと思っていますか？

関連する SLI の選択

ステップ 1

応答 / リクエスト

Storage

パイプライン

ステップ 2

SLO タイプを選択する際のベスト プラクティス

• 可能な限り、メトリクス ベースの SLO を使用してください。エラー バジェットが SLO 違反までに残された不良イベント数を反映する SLO にするのがベスト プラクティスです。また、SLO の計算はイベント数に基づいてボリューム加重されます。
• 代わりに、アップタイムを追跡し時間 ベースの SLI 計算を使用する SLO が必要な場合は、タイム スライス SLO を使用してください。モニター ベースの SLO と異なり、タイム スライス SLO では SLO 用の基盤モニターを維持する必要がありません。
• 最後に、タイム スライス SLO でカバーできないユース ケース—ノン メトリクス モニターや複数モニターに基づく SLO など—では、モニター ベースの SLO を検討してください。

SLO タイプの詳細な比較については、SLO タイプ比較 ガイドを参照してください。

SLI 計算は時間 ベースですか、それともカウント ベースですか?

Datadog では、次の SLO タイプを利用できます:

メトリクス ベース SLO

例: リクエストの 99% は、30 日間で 250 ms 未満で完了する必要があります。

• カウント ベースの SLI 計算
• SLI は正常イベントの合計を総イベント数の合計で割って計算します

モニター ベース SLO

例: すべてのユーザーリクエストのタイムレイテンシーの 99% は、いずれの 30 日の範囲内でも250 ms 未満で ある必要があります。

• 時間 ベースの SLI 計算
• SLI は基盤モニターのアップタイムに基づいて計算されます
• 1 つのモニター、複数モニター (最大 20)、またはグループ化されたマルチ アラート モニターを選択できます

新しいモニターの作成が必要な場合は Monitor create ページを開きます。

タイム スライス SLO

例: すべてのユーザーリクエストのタイムレイテンシーの 99% は、いずれの 30 日の範囲内でも250 ms 未満で ある必要があります。

• 時間 ベースの SLI 計算
• SLI はメトリクス クエリを用いて定義したカスタム アップタイムに基づいて計算されます

SLI を実装する

1. カスタムメトリクス (例: カウンター)
2. インテグレーションメトリクス (例: ロードバランサー、HTTP リクエスト)
3. Datadog APM (例: エラー、サービスのレイテンシー、リソース)
4. Datadog ログ (例: 特定のイベントの発生数に応じてログから生成されたメトリクス)

ターゲット目標および時間枠の設定

1. ターゲットを選択します: 99%、99.5%、99.9%、99.95%、または要件に適したその他の値。
2. 時間 ウィンドウを選択します: 直近のローリング 7、30、または 90 days

SLO の名前、説明、タグの追加

1. SLO に名前を付けます。
2. 説明を追加します: SLO が追跡している対象と、それがエンドユーザーのエクスペリエンスにとってなぜ重要なのかを記述します。参考としてダッシュボードのリンクを追加することもできます。
3. タグを追加します: 一般的には team および service のタグが用いられます。

ビューおよび検索

タグを使用して SLO のリストビューから SLO を検索します。

その他の参考資料

お役に立つドキュメント、リンクや記事:

Datadog で SLO のステータスとエラーバジェットを追跡するブログ サービスレベル目標入門ラーニングセンター Datadog SLO タイプの比較ドキュメント Datadog で SLO を管理するためのベストプラクティスブログ