サービスレベル目標（SLO）の設定例

オンラインで編集

例1: レイテンシ設計図を用いたアプリケーションSLO

オンラインで編集

目的： 「Robot-shop」アプリケーションの呼び出しの90%が、1週間という固定期間において平均遅延100ミリ秒未満を達成すること。

SLO の設定は以下の通りです：

  • エンティティ: ロボットショップアプリケーション

    • スコープ:
    • 境界: 全てのサービス
    • 内部呼び出しを含める: false
    • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント

  • 指標：

    • 設計図：レイテンシー
    • タイプ: 時間
    • 集計：平均
    • しきい値: 100 ミリ秒

  • 目標:

    • SLO目標：90％
    • 時間ウィンドウタイプ: ローリング
    • 時間窓の長さ：1週間

シナリオ ：SLOが 2025 年3月4日から始まる1週間のSLO時間枠において、400分の不良時間（平均遅延が100ミリ秒を超える400分）を発生したと仮定します：

このSLO のエラー予算は以下のように計算されます：

  • 期間xにおける分数 (1 - SLO目標達成率)
    • 時間枠内の総分数：1週間における24時間×60分×7分＝10080分
    • SLO目標達成率：90% ( 0.9 )
    • 誤差予算: 10080 × (1 - 0. 0.9 ) = 1008分

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × (時間枠内の総分 - 時間枠内の不良分) / 時間枠内の総分
    • 100% × (10080 総分 - 400 不良分) ÷ 10080 総分 = 96.03 %

例2: イベントベース可用性設計図を用いたWebサイトのSLO

オンラインで編集

目的： 2025年3月1日から4日間の固定期間において、デモサイトのショッピングカートページ（ cart.html ）への HTTP リクエストが95%の可用性を達成できるようにする。

SLO の設定は以下の通りです：

  • エンティティ: デモウェブサイト
    • ビーコン: HTTP リクエスト
    • カスタムフィルター: 場所 > ページ名 = カート
  • 指標：
    • 設計図：可用性
    • タイプ: イベントカウント（正しい判定と誤った判定の合計数）
  • 目標:
    • SLO目標: 95%
    • 時間枠タイプ: 固定
    • 時間窓の長さ：4日間
    • 開始: 2025年3月1日 0:00

シナリオ ： 2025年3月1 日から始まるSLO時間枠において、234件の成功した HTTP リクエストと11件の失敗した HTTP リクエストがあったと仮定します：

このSLO のエラー予算は以下のように計算されます：

  • イベント:
    • 有効なイベント数: 234 ビコン
    • 悪い出来事の回数: 11ビーコン
    • イベント総数: 234 + 11 = 245 ビコン
    • SLO目標達成率：95% ( 0.95 )
    • 誤差予算: 245 × (1 - 0.95 ) = 12 ビコン
    • 残りのエラー予算: 12 - 11 = 1 ビコン
    • エラー予算の残存割合：100% × (12 - 11) ÷ 12 = 8.33 %

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × 時間枠内の正常イベント総数 ÷ 時間枠内のイベント総数
    • 100% × 234ビーコン / 245ビーコン = 95.5 %

例3: トラフィックブループリントを用いた合成監視

オンラインで編集

目的： 2025年3月18日から1週間の固定期間中、合成監視テスト3種（ショッピングカート、ホームページ、商品一覧ページ）を毎分15回実行し、99%の達成率を定期的に維持すること。

SLO の設定は以下の通りです：

  • 対象:

    • ショッピングカートテスト
    • ホームページテスト
    • 商品一覧ページテスト

  • 指標：

    • 設計図：交通
    • しきい値: 1分あたり15件以上の結果

  • 目標:

    • SLO目標: 99%
    • 時間枠タイプ: 固定
    • 時間窓の長さ：1週間
    • 開始: 2025年3月18日 0:00

シナリオ ：SLOが 2025年3月18 日から始まるSLO時間枠において、合成テストが15回未満実行される時間が21分間存在すると仮定した場合：

このSLO のエラー予算は以下のように計算されます：

  • 期間xにおける分 (1 - SLO目標達成率)
    • 総分数：1週間あたり24時間×60分×7分＝10080分
    • SLO目標達成率: 99% ( 0.99 )
    • 誤差許容値：10080 × (1 - 0. 0.99 ) = 101分
    • 残りのエラー予算: 101 - 21 = 80
    • エラー予算の残存割合：100% × (101 - 21) / 101 = 79.21 %

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × (時間枠内の総分 - 時間枠内の不良分) / 時間枠内の総分
    • 100% × (10080分総計 - 21分の不良時間) ÷ 10080分総計 = 99.8 %

例 4：タグフィルターを使用したイベントベースの可用性による合成監視 SLO

オンラインで編集

目的： 1日という一定期間において、合成チェックアウト・ジャーニーのテストが99%以上の可用性を達成することを確認する。

SLO の設定は以下の通りです：

  • エンティティ：合成
  • スコープ:
    • 選択方法：フィルタに基づく
    • タグフィルター式： synthetic.testName startsWith "checkout"
  • 指標：
    • 設計図：可用性
    • タイプ：イベント数（良好なテスト結果と不良なテスト結果の合計数）
    • イベントが正常： call.erroneous = false
    • エラー： call.erroneous = true
  • 目標:
    • SLO目標: 99%
    • 時間枠タイプ: 固定
    • 時間ウィンドウの長さ：1日
    • 開始：2026年1月18日 0:00

シナリオ ：2026年1月18日から始まるSLOの時間枠において、14,850件の合成テストが正常に実行され、150件が失敗したと仮定する。

このSLO のエラー予算は以下のように計算されます：

  • イベント:
    • 有効なイベント数：14,850回のテスト実行
    • 失敗したテストの実行回数：150回
    • イベントの総数：14,850 + 150 = 15,000 回
    • SLO目標達成率：99% ( 0.99 )
    • 許容誤差：15,000 × (1 − 0.99 ) = 150 回の実行
    • 残りのエラー許容範囲：150 − 150 = 0 回
    • 残りのエラー許容範囲の割合：100% × (0 / 150) = 0%

SLO ステータスは以下のように計算されます：

  • SLOステータス = 正常なイベント総数 × 100% ÷ イベント総数
    • 100% × 14,850 ÷ 15,000 = 99%

例 5：カスタム・ブループリントを使用したアプリケーション SLO

オンラインで編集

目標： 1日間のローリング期間において、「Robot-shop」アプリケーションの呼び出しの98%が、 HTTP のステータスコード400を返さないことを保証する。

SLO の設定は以下の通りです：

  • エンティティ: ロボットショップアプリケーション

    • スコープ:
    • 境界: 全てのサービス
    • 内部呼び出しを含める: false
    • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント

  • 指標：

    • 設計図：カスタム
    • タイプ: イベントカウント（正しい判定と誤った判定の合計数）
    • 正常なフィルター: HTTP のステータスコードが 400 以外
    • Bad Filter: HTTP ステータスコード = 400

  • 目標:

    • SLO目標：98%
    • 時間ウィンドウタイプ: ローリング
    • 時間ウィンドウの長さ：1日

シナリオ ：SLOが 2025年3月10 日から始まる1日間のSLO時間枠において、25,000件の良好な通話と200件の不良通話があったと仮定します：

このSLO のエラー予算は以下のように計算されます：

  • イベント:
    • 有効なイベント数: 25000回
    • 悪い事象の発生回数：200件
    • 総イベント数: 25000 + 200 = 25200 回
    • SLO目標達成率：98% ( 0.98 )
    • エラー予算: 25200 × (1 - 0.98 ) = 504 回呼び出し
    • 残りのエラー予算: 504 - 200 = 304 回
    • 残りのエラー許容範囲の割合：100% × (504 - 200) ÷ 504 = 60.32 %

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × 時間枠内の正常イベント総数 ÷ 時間枠内のイベント総数
    • 100% × 25000 回 / 25200 回 = 99.2 %

例 6：イベントベースのレイテンシ・ブループリントを用いたアプリケーション SLO

オンラインで編集

目標： 「Robot-shop」アプリケーションの呼び出しの92%が、2週間の固定期間において100ミリ秒未満の遅延を達成すること。

SLO の設定は以下の通りです：

  • エンティティ: ロボットショップアプリケーション

    • スコープ:
    • 境界: 全てのサービス
    • 内部呼び出しを含める: false
    • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント

  • 指標：

    • 設計図：レイテンシー
    • タイプ: イベントカウント（正しい判定と誤った判定の合計数）
    • 良い判断：レイテンシ < 100 ミリ秒
    • 誤った判断：レイテンシが100ミリ秒以上

  • 目標:

    • SLO目標：92％
    • 時間枠タイプ: 固定
    • 時間窓の長さ：2週間
    • 開始: 2025年3月10日 0:00

シナリオ ：SLOが 2025年3月10 日から始まる2週間のSLO期間において、50,000件の良好な通話と1,000件の不良通話があったと仮定します：

このSLO のエラー予算は以下のように計算されます：

  • イベント:
    • 有効なイベント数: 50000回
    • 悪い事象の発生回数: 1000件
    • 総イベント数: 50000 + 1000 = 51000 回
    • SLO目標達成率：92%（ 0.92 ）
    • エラー予算: 51000 × (1 - 0. 0.92 ) = 4080回の呼び出し
    • 残りのエラー予算: 4080 - 1000 = 3080 回
    • エラー予算の残存率：100% × (4080 - 1000) / 4080 = 75.49 %

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × 時間枠内の正常イベント総数 ÷ 時間枠内のイベント総数
    • 100% × 50000件の呼び出し ÷ 51000件の呼び出し = 98.04 %

例 7：時間ベースの可用性ブループリントを用いたWebサイトのSLO

オンラインで編集

目的： デモサイトへの HTTP リクエストが、3日間のローリング期間において、92%の可用性と5%未満のエラー率を達成できるようにする。

SLO の設定は以下の通りです：

  • エンティティ: デモウェブサイト
    • ビーコン: HTTP リクエスト
  • 指標：
    • 設計図：可用性
    • タイプ: 時間
    • エラー率閾値：5％
  • 目標:
    • SLO目標：92％
    • 時間ウィンドウタイプ: ローリング
    • 時間窓の長さ：3日間

シナリオ ：SLOが 2025年3月5 日から始まる3日間のSLO時間枠において、200分の不良時間（平均誤り率が5%を超える200分）があったと仮定する：

このSLO のエラー予算は以下のように計算されます：

  • 期間xにおける分数 (1 - SLO目標達成率)
    • 時間枠内の総分数：3日間における24時間×60分×3分＝4320分
    • SLO目標達成率：92%（ 0.92 ）
    • 誤差予算: 4320 × (1 - 0.92 ) = 346 分

SLO ステータスは以下のように計算されます：

  • SLOステータス = 100% × (時間枠内の総分 - 時間枠内の不良分) / 時間枠内の総分
    • 100% × (4320分総計 - 200分不良) ÷ 4320分総計 = 95.37 %

例 8: 時間ベースの飽和ブループリントを用いたインフラストラクチャ SLO（CPU）

オンラインで編集

目的： 本番ホストにおけるCPU使用率が、7日間のローリング期間において99%の時間で75%未満に維持されることを保証する。

SLO の設定は以下の通りです：
  • エンティティ: インフラストラクチャ
    • インフラストラクチャの種類: ホスト
    • タグフィルター式: availabilityZone = "us-east-1"
  • 指標：
    • ブループリント：飽和
    • タイプ: 時間
    • メトリック: cpu.used
    • 集計: 平均
    • 演算子: >=
    • 閾値：75％
  • 目標:
    • SLO目標: 99%
    • 時間ウィンドウタイプ: ローリング
    • 時間ウィンドウの長さ：7日間
シナリオ ：SLOが 2025年3月15 日から始まる7日間のSLO時間枠において、25分の不良時間（平均CPU使用率≥75%の25分間）があったと仮定します：このSLO のエラー予算は以下のように計算されます：
  • 期間xにおける分数 (1 - SLO目標達成率)
    • 時間枠内の総分数：1週間における24時間×60分×7分＝10080分
    • SLO目標達成率：99% ( 0.99 )
    • 誤差許容値：10080 × (1 - 0. 0.99 ) = 101分
SLO ステータスは以下のように計算されます：
  • SLOステータス = 100% × (時間枠内の総分 - 時間枠内の不良分) / 時間枠内の総分
    • 100% × (10080分総計 - 25分の不良時間) ÷ 10080分総計 = 99.75 %

例 9: イベントベースのサチュレーション・ブループリントを用いたインフラストラクチャ SLO（メモリ）

オンラインで編集

目的： データベースサーバーにおけるメモリ使用率が、1日間のローリング期間におけるメトリクススナップショットの 99.9 ％において、85％未満に維持されることを保証する。

SLO の設定は以下の通りです：
  • エンティティ: インフラストラクチャ
    • インフラストラクチャの種類: ホスト
    • タグフィルター式: host.fqdn contains "company-name" AND availabilityZone = "us-east-1"
  • 指標：
    • ブループリント：飽和
    • タイプ: イベントカウント（正常なメトリクススナップショットと異常なメトリクススナップショットの合計数）
    • メトリック: memory.used
    • 演算子: >=
    • 閾値: 85%
  • 目標:
    • SLO目標: 99.9 %
    • 時間ウィンドウタイプ: ローリング
    • 時間ウィンドウの長さ：1日
シナリオ ： 2025 年3月20日から始まるSLO時間枠において、8,640件の正常なメトリクススナップショット（メモリ使用率 < 85%）と5件の異常なメトリクススナップショット（メモリ使用率 ≥ 85%）が存在すると仮定します。このSLO のエラー予算は以下のように計算されます：
  • イベント:
    • 良いイベントの合計：8,640スナップショット
    • 悪い出来事の回数: 5回
    • 総イベント数: 8,640 + 5 = 8,645 スナップショット
    • SLO目標達成率： 99.9 % ( 0.999 )
    • エラー予算: 8,645 × (1 - 0.999 ) = 8.65 スナップショット (9に丸め)
    • 残りのエラー予算: 9 - 5 = 4 スナップショット
    • エラー予算の残存割合：100% × (9 - 5) ÷ 9 = 44.44 %
SLO ステータスは以下のように計算されます：
  • SLOステータス = 100% × 時間枠内の正常イベント総数 ÷ 時間枠内のイベント総数
    • 100% × 8,640 スナップショット ÷ 8,645 スナップショット = 99.94 %

例 10: Kubernetes クラスター用のカスタム・ブループリントを用いたインフラストラクチャ SLO

オンラインで編集

目的： Kubernetes クラスターが、7日間のローリング期間において、 99.9 %の時間、少なくとも6つの利用可能なノードを維持することを保証する。

SLO の設定は以下の通りです：
  • エンティティ: インフラストラクチャ
    • インフラストラクチャの種類: Kubernetes Cluster
    • タグフィルター式: kubernetes.cluster.name = "prod-cluster"
  • 指標：
    • 設計図：カスタム
    • タイプ: イベントカウント（正常なメトリクススナップショットと異常なメトリクススナップショットの合計数）
    • 良好なイベント: nodes.count >= 6
    • 悪い事象: nodes.count < 6
  • 目標:
    • SLO目標: 99.9 %
    • 時間ウィンドウタイプ: ローリング
    • 時間ウィンドウの長さ：7日間
シナリオ ：7日間のSLO時間枠（ 2025-04-01:The 開始）において、良好なイベント（ノード数が6以上のメトリクススナップショット）が60,400件、不良なイベント（ノード数が6未満のメトリクススナップショット）が80件発生したと仮定します。このSLOに対するエラー予算は以下のように計算されます：
  • イベント:
    • 良いイベントの合計：60,400スナップショット
    • 悪い出来事の回数: 80回
    • 総イベント数: 60,400 + 80 = 60,480 スナップショット
    • SLO目標達成率： 99.9 % ( 0.999 )
    • エラー予算: 60,480 × (1 - 0.999 ) = 60.48 スナップショット (60に丸め)
    • エラー予算残量: 60 - 80 = -20 スナップショット (超過)
    • エラー予算の残存割合：100% × (-20 / 60) = -33.33 % (超過使用)
SLO ステータスは以下のように計算されます：
  • SLOステータス = 100% × 時間枠内の正常イベント総数 ÷ 時間枠内のイベント総数
    • 100% × 60,400 スナップショット ÷ 60,480 スナップショット = 99.87 %

例 11: タイムゾーンのバインディングによる SLO の挙動

オンラインで編集

目的：正確かつ一貫性のあるレポート作成のため、SLOの時間枠がカレンダー上の 時刻と一致し、夏時間の切り替え時を含め、毎日同じままであることを確認する。 SLOの計算は特定のタイムゾーンに紐づけるようにしてください。夏時間の切り替えは、設定されたタイムゾーンに応じて時間枠に影響を与えるためです。

SLO の設定は以下の通りです：
  • エンティティ: ロボットショップアプリケーション
    • スコープ:
      • 境界: 全てのサービス
      • 内部呼び出しを含める: false
      • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント
  • 指標：
    • 設計図：レイテンシー
    • タイプ: 時間
    • 集計：平均
    • しきい値: 100 ミリ秒
  • 目標:
    • SLO目標：90％
    • 時間枠タイプ: 固定
    • 時間窓の長さ：3日間
    • タイムゾーンを固定: 有効
    • タイムゾーン: Europe/Berlin
シナリオ ：ユーザーは 2 025年3月29日から3日間のサービスレベル目標（SLO）を有している。 このSLOはベルリンの夏時間移行期間と重なります。 その時間枠は一貫性を保つべきであり、各日は同じ時分（分）で開始および終了すべきである。夏時間（DST）の時刻変更が発生する2025年3月30日もこれに含まれる。

例12：チームに関連付けられたSLO

オンラインで編集

目的：SLOを、ユーザー に関連付けられた1つ以上のチームに割り当てる。 これらのチーム関連付けは、アクセス制限を適用するために利用されます。

以下の例は、チーム関連付けを持つSLO の設定を示しています：

  • エンティティ: ロボットショップアプリケーション

    • スコープ:
      • 境界: 全てのサービス
      • 内部呼び出しを含める: false
      • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント

  • 指標：

    • 設計図：レイテンシー
    • タイプ: 時間
    • 集計：平均
    • しきい値: 100 ミリ秒

  • 目標:

    • SLO目標：90％
    • 時間ウィンドウタイプ: ローリング
    • 時間窓の長さ：1週間

  • 詳細:

    • 名称: サンプルSLO
    • タグ（任意）：サンプルタグ
    • チーム：チーム1、チーム2
シナリオ ：ユーザーには、チーム1とチーム2の両方に割り当てられたSLOがあります。 対応するチームラベルはSLOテーブルおよび設定ページで確認できます。 チームスコープに切り替えると、選択したチームに基づいて、このSLOのユーザービューが制限されます。

例 13：月の半ばに作成された暦月単位のSLO

オンラインで編集

目標：1月15日に作成されたSLOに基づき、「決済サービス」アプリケーションへの全コールの99%が、暦月単位で平均遅延時間200ミリ秒未満を達成すること。

SLO の設定は以下の通りです：

  • エンティティ: 決済サービスアプリケーション
    • スコープ:
      • 境界: 着信
      • 内部呼び出しを含める: false
      • 合成コールを含める: false
    • サービス：すべてのサービス
    • エンドポイント: すべてのエンドポイント
  • 指標：
    • 設計図：レイテンシー
    • タイプ: 時間
    • 集計：平均
    • しきい値: 200 ミリ秒
  • 目標:
    • SLO目標: 99%
    • 時間枠タイプ: 固定
    • 時間窓の長さ：1暦月
    • タイムゾーンを固定: 有効
    • タイムゾーン: America/New_York
    • 開始: 2025年1月15日 00:00

シナリオ ：SLOは2025年1月15日に作成される。 カレンダー月のSLOは月の境界と連動するため、月の中旬に作成された場合、最初の期間が部分的に設定されます。

初期期間（2025年1月15日～31日） ：
  • 期間：17日間（1月15日から1月31日まで）
  • 合計分数：17 × 24 × 60 = 24,480 分
  • 誤差予算：24,480 × (1 - 0. 0.99 ) = 245分
  • 記録された悪い時間：30分
  • SLOステータス: 100% × (24,480 - 30) / 24,480 = 99.88 %
  • 残りのエラー予算: 245 - 30 = 215 分
第二期（2025年2月1日～28日） ：
  • 期間：28日間（完全な暦月）
  • 総分数：28 × 24 × 60 = 40,320 分
  • 誤差許容値：40,320 × (1 - 0. 0.99 ) = 403分
  • 記録された悪い時間：50分
  • SLOステータス: 100% × (40,320 - 50) / 40,320 = 99.88 %
  • 残りのエラー予算: 403 - 50 = 353 分
第3期（2025年3月1日～31日） ：
  • 期間：31日間（完全な暦月）
  • 総分数：31 × 24 × 60 = 44,640 分
  • 誤差予算: 44,640 × (1 - 0. 0.99 ) = 446分

例 14：月の初日に作成される暦月単位のSLO

オンラインで編集

目標：3月1日に作成されたSLOに基づき、「Eコマースウェブサイト」への HTTP リクエストの95%が、暦月単位で可用性を達成することを保証する。

SLO の設定は以下の通りです：

  • エンティティ：Eコマースウェブサイト
    • ビーコン: HTTP リクエスト
    • カスタムフィルター: なし
  • 指標：
    • 設計図：可用性
    • タイプ: 時間
    • エラー率閾値：5％
  • 目標:
    • SLO目標: 95%
    • 時間枠タイプ: 固定
    • 時間窓の長さ：1暦月
    • タイムゾーンを固定: 有効
    • タイムゾーン: UTC
    • 開始: 2025-03-01 00:00

シナリオ ：SLOは2025年3月1日（その月の最初の日）に作成される。 すべての測定期間は完全な暦月です。

第1期（2025年3月1日～31日） ：
  • 期間：31日間（完全な暦月）
  • 総分数：31 × 24 × 60 = 44,640 分
  • 誤差予算: 44,640 × (1 - 0.95 ) = 2,232 分
  • 記録された不良時間：400分
  • SLOステータス: 100% × (44,640 - 400) / 44,640 = 99.10 %
  • 残りのエラー予算: 2,232 - 400 = 1,832 分
第二期（2025年4月1日～30日） ：
  • 期間：30日間（暦月単位）
  • 総分数：30 × 24 × 60 = 43,200 分
  • 誤差予算：43,200 × (1 - 0. 0.95 ) = 2,160 分
  • 記録された悪い時間：350分
  • SLOステータス: 100% × (43,200 - 350) / 43,200 = 99.19 %
  • 残りのエラー予算: 2,160 - 350 = 1,810 分

サービスレベルに関するスマートアラートの設定例

オンラインで編集

例 1：SLO のステータスを監視するためのサービスレベル・スマートアラート

オンラインで編集

目的： 自動販売機の信頼性SLO設定のステータスが90%未満の場合、アラートを発し問題を通知する。

「サービスレベル」スマートアラートの設定は、以下のようになります：

Rule:
  Alert Type: Service Levels Objective
  Metric: Status
Threshold:
  Operator: <
  value: 0.90
SLOs: Vending Machine Reliability
Time Threshold:
  Expiry: 5 Minutes
  Time window: 10 Minutes

スマートアラートの設定が完了すると、システムは自動販売機の信頼性に関するSLO設定の状態の監視を開始します。

シナリオ：監視とイベントトリガー

オンラインで編集

  • SLOが閾値を下回る

    • 自動販売機の信頼性SLOが89%に低下し、定義された閾値である90%を下回ったと仮定する。
    • 時間閾値が10分に設定されている場合、システムは10分間の全期間を待機した後、初めて何らかのアクションを実行します。
    • SLOが10分経過後も90%を下回った場合、システムはイベントをトリガーし、問題を発生させます。

  • SLOがしきい値を超過

    • 一定期間経過後、SLOステータスが回復し90%を超えた場合、システムは監視を継続します。
    • ただし、ステータスが90%を超える状態が続く場合、システムは5分間の有効期限閾値を待機します。
    • SLOが5分間全体を通じて90%を上回った場合、イベントは自動的に終了します。

例 2：SLOのエラー許容範囲を監視するためのサービスレベル・スマートアラート

オンラインで編集

目的： 自動販売機の信頼性SLO設定におけるエラー予算消費率が50%を超えた場合に、警告を発し問題を報告する。

「サービスレベル」スマートアラートの設定は以下の通りです：

Rule:
  Alert Type: Error Budget
  Metric: Burned Percentage
Threshold:
  Operator: >
  value: 0.50
SLOs: Vending Machine Reliability
Time Threshold:
  Expiry: 5 Minutes
  Time window: 10 Minutes

スマートアラートの設定が完了すると、システムは自動販売機の信頼性に関するSLO設定におけるエラー許容範囲の使用率の監視を開始します。

シナリオ：監視とイベントトリガー

オンラインで編集

  • エラー予算の消費量が50%を超過しました

    • エラー予算の消費が50％を超えると仮定する。
    • 時間閾値が10分に設定されている場合、システムは10分間の全期間を待機した後、初めて何らかのアクションを実行します。
    • エラー予算の消費量が10分経過後も50%を超える場合、システムはイベントをトリガーし、問題を発生させます。

  • エラー予算の消費率が50%を下回った

    • 一定時間経過後、エラー予算の消費率が50%を下回った場合、システムは監視を継続します。
    • エラー予算の消費量が50%未満に留まる場合、システムは5分間の期限切れ閾値を待機します。
    • エラー予算の消費量が5分間全体を通じて50％未満に留まる場合、イベントは自動的に終了します。

サービスレベル、バーンレート、スマートアラートの計算

オンラインで編集

バーンレートは次の式を用いて計算される：

バーンレート = (消費されたエラー予算 * SLO時間枠) / アラート発動時間枠

  • 例:
    • 過去12時間におけるエラー予算の消費率が70%であり、自動販売機の信頼性SLOのSLO時間枠が1日（24時間）であると仮定します。
    • 過去12時間の消費率は次のようになります： ( 0.70 * 24) / 12 = 1.4
    • 同様に、過去2時間のエラー予算の消費量が20%である場合
    • 過去2時間の消費率は次のようになります： ( 0.20 * 24) / 2 = 2.4

例3 - 単一のアラートウィンドウとしきい値でSLOのバーンレートを監視するスマートアラート

オンラインで編集

目的：自動販売機の信頼性SLO設定における過去12時間のバーンレートが1を超える場合に、アラートを発し問題を通知する。

「サービスレベル」スマートアラートの設定は、以下の通りであるべきです：

Rule:
  Alert Type: Error Budget
  Metric: Burn Rate V2
Burn Rate Config:
[
  Alert Window Type: SINGLE
  Duration: 12 Hours
  Duration Unit Type: Hour
  Threshold:
    Operator: >
    Value: 1
]
SLOs: Vending Machine Reliability
Time Threshold:
  Expiry: 5 Minutes
  Time window: 10 Minutes

スマートアラートの設定が完了すると、システムは指定されたアラート期間について、自動販売機の信頼性SLO設定の消費率の監視を開始します。

シナリオ：監視とイベントトリガー

オンラインで編集

  • アラート対象期間（過去12時間）におけるバーンレートが1を超過

    • 過去12時間の計算済み燃焼率が1を超え始めたと仮定する。
    • 時間閾値が10分に設定されている場合、システムは10分間の全期間を待機した後、初めて何らかのアクションを実行します。
    • 燃焼率が10分経過後も1を超える場合、システムは警告イベントをトリガーし、問題を発生させます。

  • アラート対象期間（過去12時間）におけるバーンレートが1を下回った

    • アラート対象期間の燃焼率が一定時間後に1を下回った場合、システムは監視を継続する。
    • 燃焼率が1未満の場合、システムは5分間の有効期限閾値を待機します。
    • 燃焼率が5分間を通じて1未満のままの場合、イベントは自動的に終了します。

例4 - 複数のアラートウィンドウと対応する閾値を持つSLOの燃焼率を監視するスマートアラート

オンラインで編集

目的：自動販売機の信頼性SLO設定における過去24時間のバーンレートが1を超え、かつ過去2時間のバーンレートが4を超える場合に、アラートを発し問題を通知する。

「サービスレベル」スマートアラートの設定は、以下の通りであるべきです：

Rule:
  Alert Type: Error Budget
  Metric: Burn Rate V2
Burn Rate Config:
[
  Alert Window Type: LONG
  Duration: 24 Hours
  Duration Unit Type: Hour
    Threshold:
    Operator: >
    Value: 1
  ,
  Alert Window Type: SHORT
  Duration: 2 Hours
  Duration Unit Type: Hour
  Threshold:
    Operator: >
    Value: 4
]
SLOs: Vending Machine Reliability
Time Threshold:
  Expiry: 5 Minutes
  Time window: 10 Minutes

スマートアラートの設定が完了すると、システムは、長期および短期のアラート期間の両方について、「自動販売機の信頼性」SLO設定のバーンレートの監視を開始します。

シナリオ：監視とイベントトリガー

オンラインで編集

  • 長短両方のアラート期間（過去24時間および過去2時間）において、バーンレートが1を超過しています

    • 過去24時間の計算済み燃焼率が1を超え始め、過去2時間の計算済み燃焼率が4を超え始めたと仮定する。
    • 時間閾値が10分に設定されている場合、システムは10分間の全期間を待機した後、初めて何らかのアクションを実行します。
    • 両方のアラートウィンドウのバーンレートが10分経過後も閾値を超過している場合、システムはアラートイベントをトリガーし、問題を発生させます。

  • 長期アラートウィンドウではバーンレートが1を下回るが、短期アラートウィンドウでは4を上回る状態が続く

    • 長いアラートウィンドウの燃焼率が1を下回った後も、短いアラートウィンドウの燃焼率が4を上回り続ける場合、システムは監視を継続する。
    • バーンレートが長いアラート期間中ずっと1未満の場合、システムは5分間の期限切れ閾値を待機します。
    • 長いアラートウィンドウのバーンレートが5分間を通じて1未満の場合、短いアラートウィンドウの値にかかわらず、イベントは自動的にクローズされます。アラートを送信するには両方のしきい値が違反されている必要があるためです。 逆の場合も同様である——短い警報期間が閾値を超過しても、長い警報期間が閾値を超過しない場合であっても。

  • 長期アラートウィンドウではバーンレートが1を下回り、短期アラートウィンドウでは4を下回る

    • 一定時間後、両方のアラートウィンドウの燃焼率がそれぞれの閾値を下回った場合、システムは監視を継続する。
    • 燃焼率が閾値を下回ったままの場合、システムは5分間の有効期限閾値を待機する。
    • 燃焼率が5分間全体にわたって閾値を下回った場合、イベントは自動的に終了する。
注記： 複数のウィンドウを持つバーンレートアラートは、両方のしきい値（AND条件）が違反された場合にのみアラートを送信します。 たとえ一つのしきい値が違反されていなくても、アラートは送信されない。

トラブルシューティング

オンラインで編集

設定SLOで頻繁に発生する問題を解決するための提案は以下の通りです。

  • 問題 : エラー予算が消費されないため、SLOステータスが常に100%となる。

    • 解決策 : SLOダッシュボードのインジケーターチャートを使用し、SLO時間枠内でインジケーターがしきい値を超過しないことを確認します。これにより、エラー予算が消費されません。 必要に応じてしきい値を変更することをご検討ください。

  • 問題 : エラー予算が消費されないため、SLOステータスが常に100%となる。

    • 解決策 : SLOダッシュボードのトラフィックチャートを使用して、エンティティがSLO時間枠中にトラフィックを受信していることを確認します。 そうでない場合、エラー予算とSLOステータスには影響しません。

  • 問題 ：エラー予算が一貫して急速に消費され、SLOステータスがネガティブな状態のままです。

    • 解決策 : SLOダッシュボードのインジケーターチャートを使用して、SLOの時間枠内でインジケーターがしきい値を一貫して超過しているかどうかを確認し、エラー予算の急速な消費を引き起こしていることを検証します。 必要に応じてしきい値を変更することをご検討ください。

  • 問題 ：時間枠の不一致により、バーンレートアラートがトリガーされない。

    • 解決策 ：
      • 固定時間枠のSLO : SLOが固定時間枠で設定されている場合、バーンレートの計算がSLO期間内の実際の経過時間よりも長いアラート対象期間に基づいて行われると、アラートがトリガーされない可能性があります。 例えば、アラート対象期間が12時間分のデータを必要とする場合、SLOの時間枠が開始したばかりであれば、バーンレートが閾値を超えるのに十分な時間が確保できない可能性がある。 その結果、経過時間中に燃焼速度が高くても、アラートは発生しません。
      • ローリング時間ウィンドウ SLO : SLO がローリング時間ウィンドウに設定されている場合、アラート対象期間が SLO の作成時刻を超えて延長されると、バーンレートの計算がアラートをトリガーしない可能性があります。 例えば、アラート対象期間がSLOの作成時または有効期間を超過している場合、アラート対象期間全体にわたるデータが利用できないため、バーンレートを適切に計算できません。