SLOモニタリング

概要

既存または新規の Datadog モニターに基づいて SLO を構築する場合は、モニターベースのソースを選択します。モニターの詳細については、モニターのドキュメントを参照してください。モニターベースの SLO は、時間ベースのデータストリームで、良い動作と悪い動作の時間を区別するのに役立ちます。良い時間の合計を合計時間の合計で割った値を使用すると、サービスレベル指標（SLI）が得られます。

セットアップ

SLO ステータスページで New SLO + を選択します。その後、Monitor をクリックします。

クエリの定義

開始するには、Datadog モニターを使用する必要があります。新しいモニターをセットアップするには、モニター作成ページに移動し、SLO でサポートされているモニターの種類のいずれかを選択します（以下にリストされています）。名前でモニターを検索し、それをクリックしてソースリストに追加します。

たとえば、ユーザーリクエストのレイテンシーが 250 ミリ秒を超えるとアラートを出すように構成されたメトリクスモニターがある場合、そのモニターにモニターベースの SLO を設定できます。過去 30 日間で 99% の SLO ターゲットを選択したとします。これが意味するのは、ユーザーリクエストのレイテンシーは過去 30 日間の 99% の時間で 250 ミリ秒未満でなければならないということです。これを設定するには、次のようにします。

1. 単一のモニターを選択するか、
2. 複数のモニター（最大 20）を選択するか、
3. 単一の マルチアラートモニター を選択し、Calculate on selected groups トグルを使って SLO 計算に含める特定のモニターグループ（最大 20）を選択します。

サポートされるモニターの種類:

• メトリクスモニターの種類 (メトリクス、インテグレーション、APM メトリクス、異常検知、予測値、外れ値)
• Synthetic
• サービスチェック (オープンベータ)

例: 物理デバイスの稼働時間を追跡している場合を考えます。カスタムメトリクスを使用して、host:foo のメトリクスモニターを既に構成しているとします。また、このモニターは、到達できなくなった場合に、オンコールチームに ping を送信する場合があります。バーンアウトを回避するために、このホストがダウンしている頻度を追跡する必要があります。

SLO ターゲットの設定

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 にも適用できます)。

この場合は、全体的なステータスが個々のステータスの平均よりも低いという結果になります。

Synthetic テストの例外

場合によっては、1 つのグループ化された Synthetic テストで構成されるモニターベースの SLO のステータス計算に例外があります。Synthetic テストには、テストが ALERT 状態に入るときの動作を変更し、その結果、全体的なアップタイムに影響を与えるオプションの特別なアラート条件があります。

• グループが指定された分数の間失敗するまで待ちます (デフォルト: 0)
• 指定された数のグループが失敗するまで待ちます (デフォルト: 1)
• ロケーションのテストが失敗と見なされる前に、指定された回数再試行します (デフォルト: 0)

これらの条件のいずれかをデフォルト以外に変更することにより、その 1 つの Synthetic テストのみを使用するモニターベースの SLO の全体的なステータスは、Synthetic テストの個々のグループの集計ステータスよりも優れているように見える可能性があります。

Synthetic テストのアラート条件の詳細については、Synthetic モニタリングドキュメントにアクセスしてください。

基底のモニターと SLO 履歴

メトリクスモニターの種類に基づく 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 をサポートしています。

その他の参考資料

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

モニターの詳細ドキュメント