- 重要な情報
- アプリ内
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
新規または既存の Datadog モニターから SLO を構築するには、モニターベースの SLO を作成します。
時間ベースのデータセットは、通常、モニターベースの SLO にうまく対応します。モニターベースの SLO を使用すると、システムが正常な動作を示した時間を総時間で割ることで、 サービスレベル指標 (SLI) を計算することができます。
モニターベースの SLO を作成するには、既存の Datadog モニターが必要です。新しいモニターをセットアップするには、モニター作成ページにアクセスします。
Datadog のモニターベースの SLO は、以下のモニタータイプをサポートしています。
SLO ステータスページで New SLO を選択します。
Define the source で、Monitor Based を選択します。
検索ボックスで、モニターの名前を入力し始めます。一致するモニターのリストが表示されます。モニター名をクリックすると、そのモニターがソースリストに追加されます。
SLO で単一のマルチアラートモニターのみを使用する場合、オプションで “Calculate on selected groups” (選択したグループ で計算) を選択し、最大 20 グループを選択することができます。グループ選択は、複数のモニターを含む SLO には対応していません。
目標パーセンテージ、タイムウィンドウ*、オプションで警告レベルを選択します。
目標パーセンテージは、SLO の基礎となるモニターが ALERT 状態であってはならない時間の割合を指定します。
タイムウィンドウは、SLO が計算を実行するローリング期間を指定します。
SLI の値に応じて、Datadog UI は SLO のステータスを異なる色で表示します。
選択したタイムウィンドウによって、モニターベースの SLO に利用できる精度が変わります。
SLO の詳細 UI では、7 日および 30 日のタイムウィンドウで構成された SLO については小数点以下 2 桁、90 日のタイムウィンドウで構成された SLO については小数点以下 3 桁が Datadog に表示されます。
次の例は、Datadog が SLO 計算の小数点以下の桁数を制限して表示する理由を示しています。7 日または 30 日のタイムウィンドウで 99.999% の目標を設定すると、それぞれ 6 秒または 26 秒のエラーバジェットが発生します。モニターは 1 分ごとに評価するため、モニターベースの SLO の粒度も 1 分となります。したがって、1 つのアラートで、前の例の 6 秒または 26 秒のエラーバジェットが完全に消費され、過剰に使用されることになります。実際には、チームはこのような小さなエラーバジェットを満足させることはできません。
1 分間に 1 回のモニター評価よりも細かい粒度が必要な場合は、代わりにメトリクスベースの SLO を使用することを検討してください。
SLO の名前と詳細な説明を選択します。SLO に関連付けるタグを選択します。
Save & Exit を選択し、新しい SLO を保存します。
Datadog は、特定のグループが選択されていない限り、すべてのモニターまたはモニターグループのアップタイム率として、全体的な SLO ステータスを計算します。特定のグループが選択されている場合、SLO ステータスはそれらのグループのみを使って計算されます。特定のグループが選択されていない場合、UI はステータスが最も悪い 5 つのグループを表示します。
モニターベースの SLO は、WARN 状態を OK として扱います。SLO の定義には、良い動作と悪い動作の二元的な区別が必要です。SLO の計算では、WARN は悪い動作を示すほど深刻ではないため、WARN を良い動作として扱います。
3 つのモニターを含むモニターベースの SLO の次の例を考えます。1 台のマルチアラートモニターに基づくモニターベースの 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 モニタリングを参照してください。
モニターが手動で解決された場合、または After x hours automatically resolve this monitor from a triggered state (x 時間後、このモニターをトリガー状態から自動的に解決する) 設定の結果として、SLO 計算が変更されることはありません。これらがワークフローにとって重要なツールである場合、モニターのクローンを作成し、自動解決設定と@-notification 設定を削除し、SLO にクローンを使用することを検討してください。
Datadog では、SLO の下地として Alert Recovery Threshold と Warning Recovery Threshold を持つモニターを使用しないことを推奨しています。これらの設定は、SLI の良い動作と悪い動作をきれいに区別することを難しくします。
モニターをミュートしても、SLO の計算には影響しません。
SLO の計算から期間を除外するには、SLO ステータス修正機能を使用します。
メトリクスモニターまたはサービスチェックを作成する際に、データが欠落している場合にアラートを送信するかどうかを選択します。この構成は、モニターベースの SLO 計算が欠落データをどのように解釈するかに影響します。欠落データを無視するように構成されたモニターの場合、欠落データのある時間帯は、SLO によって OK (アップタイム) として扱われます。欠落データにアラートを出すように構成されたモニターの場合、欠落データのある時間帯は、SLO によってアラート (ダウンタイム) として扱われます。
Synthetic テストを一時停止すると、SLO はデータが欠落している期間を計算から除外します。UI では、これらの期間は SLO ステータスバーで薄いグレーで表示されます。
メトリクスモニタータイプに基づく SLO には、SLO Replay という機能があり、基礎となるモニターのメトリクスとクエリ構成から取り出した履歴データで SLO ステータスを埋め戻します。新しいメトリクスモニターを作成し、その新しいモニターに SLO を設定する場合、SLO のステータスを表示するために 7 日、30 日、または 90 日間待つ必要はありません。その代わり、SLO Replay は新しい SLO を作成したときにトリガーされ、モニターの基礎となるメトリクスとクエリの履歴を調べて、ステータスを記入します。
SLO Replay は、基礎となるメトリクスモニターのクエリを変更して、新しいモニター構成に基づいてステータスを修正した場合にもトリガーされます。SLO Replay が SLO のステータス履歴を再計算する結果、モニターの更新後、モニターのステータス履歴と SLO のステータス履歴が一致しない場合があります。
注: Synthetic テストまたはサービスチェックに基づく SLO は、SLO Replay をサポートしません。
使用するケースに適した SLI タイプを使用していることを確認します。Datadog は、モニターベースの SLI とメトリクスベースの SLI をサポートしています。
お役に立つドキュメント、リンクや記事:
