SLOモニタリング
Dash が新機能を発表!インシデントマネジメント、Continuous Profiler など多数の機能が追加されました! Dash イベントで発表された新機能!

SLOモニタリング

概要

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

セットアップ

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

クエリの定義

開始するには、Datadog モニターを使用する必要があります。新しいモニターをセットアップするには、モニター作成ページに移動し、SLO でサポートされているモニターの種類のいずれかを選択します(以下にリストされています)。名前でモニターを検索し、それをクリックしてソースリストに追加します。モニターの SLO の例として、すべてのユーザーリクエストのレイテンシーが 30 日間の 99% の時間で 250ms 未満であるかどうかが挙げられます。これを設定するには、次のようにします。

  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 か月の例で考えてみましょう。

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

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

基底のモニターと 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 をサポートしています。

その他の参考資料

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