トンネルヘルスアラートは、トンネル接続の信頼性が許容しきい値を下回ったときに通知します。Cloudflare がこのアラートをどう算出するかを理解すると、通知の意味を読み取り、短時間で回復する問題と、対応が必要な継続的な劣化を区別しやすくなります。
Cloudflare は、短期と長期の指標を組み合わせた複数ウィンドウ方式を使います。一時的な問題ではアラートを出さず、実際の劣化は検出します。次のセクションで、この仕組みの要点を説明します。
SLI は、成功したイベント数を全イベント数で割った比率です。SLI が 0% なら機能はまったく動いていません。SLI が 100% なら、機能は想定どおりに動いています。
SLO は SLI のしきい値であり、IPsec / GRE トンネルの信頼性の目標水準を定めます。たとえば、過去 30 日間のトンネル状態のうち 99.9% が健全である、といった SLO です。Cloudflare は、トンネルヘルスチェックのタイムアウト結果ではなく、down トンネル状態の値 に基づいて SLO 向けの SLI を算出します。
エラーバジェットは、SLO が定める可用性を維持したまま、SLO の期間中に許容できる失敗イベントの量です。
SLO は目標のパーセンテージであり、エラーバジェットは 100% から SLO を引いた値です。たとえば、30 日間にアカウントで 100 万回のトンネルヘルスチェックがあり、SLO が 99.9% の場合、エラーバジェットは次のとおりです。
number of events x (1 - SLO) = 1,000,000 x (1-0.999) = 1,000つまり、この SLO では 30 日間に 1,000 回の失敗したトンネルヘルスチェックを許容します。ただし、その失敗が 30 日ではなく 1 時間に集中したらどうなるでしょうか。ここからバーンレートの考え方が出てきます。
バーンレートは、SLO の期間に対して、ある時間ウィンドウでエラーバジェットをどれだけ速く消費するかを測ります。この例では、SLO 99.9% なら 30 日間に 1,000 回のトンネルヘルスチェック失敗を観測できます。ただし、同じ 1,000 回の失敗を 1 時間で起こすことは許容できません。
トンネルヘルスアラートを送るタイミングは、複数ウィンドウかつ複数バーンレートの方式で決めます。Cloudflare は 5 分ごとに、直近 1 時間と直近 5 分のデータを分析します。短いウィンドウ（5 分）と長いウィンドウ（1 時間）のそれぞれで SLI を算出します。
アラートが出るのは、短いウィンドウと長いウィンドウの両方が、設定したしきい値を下回ったときだけです。つまり、両方のウィンドウがしきい値を満たさない場合にアラートが発火します。しきい値を 99% にした場合の例は次のとおりです。
- 短いウィンドウ: 99.2%、長いウィンドウ: 99%。短いウィンドウが 99% を超えているため、Cloudflare はアラートを出しません。
- 短いウィンドウ: 98%、長いウィンドウ: 98%。両方のウィンドウが 99% を下回るため、Cloudflare はアラートを出します。