SLOモニタリング
Incident Management が一般に使用できるようになりました。 Incident Management が広範に使用できるようになりました。

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 と関連付けたいタグ内に、SLO の目的についてのコンテキスト情報を関連情報またはリソースも含めて追加できます。

全体的なステータスの計算

全体的なステータスとは、単一のマルチアラートモニターで、すべてのモニターやすべての計算済みグループが OK の状態である時間の割合のことです。モニターを集計した平均値でも、グループを集計した平均値でもありません。

3 台のモニターの次の例を検討してください (これは、単一のマルチアラートモニターに基づくモニターベースの SLO にも適用できます)。

モニターt1t2t3t4t5t6t7t8t9t10ステータス
モニター 1OKOKOKOKアラートOKOKOKOKOK90%
モニター 2OKOKOKOKOKOKOKOKアラートOK90%
モニター 3OKOKアラートOKアラートOKOKOKOKOK80%
全体的なステータスOKOKアラートOKアラートOKOKOKアラートOK70%

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

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 ThresholdWarning Recovery Threshold を備えたモニターを使用しないことを推奨します。これらは、SLO 計算にも影響を与え、SLI の良い動作と悪い動作を明確に区別できないためです。

SLO の計算には、モニターが手動で解決される場合、または After x hours automatically resolve this monitor from a triggered state(x 時間後に、このモニターをトリガー状態から自動的に解決する)設定の結果として解決される場合は考慮されません。これらがワークフローにとって重要なツールである場合は、モニターを複製し、自動解決設定と @-notification を削除して、SLO に複製を使用することを検討してください。

ユースケースに適した SLI タイプを使用していることを確認してください。SLO イベントのドキュメントに記載の通り、Datadog は、モニターベースの SLI とメトリクスベースの SLI をサポートしています。

その他の参考資料

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