トンネルヘルスアラートは、トンネル接続の信頼性が許容しきい値を下回ったときに通知します。Cloudflare がこれらのアラートを計算する仕組みを理解すると、通知の意味を解釈し、短時間で回復する問題と、対応が必要な持続的な問題を区別しやすくなります。
Cloudflare は、短期と長期の指標を組み合わせる複数ウィンドウ方式を使い、一時的な問題ではアラートを出さず、実際の劣化は検出します。次のセクションで、この処理の要点を説明します。
SLI は、全体のイベントに対する成功イベントの比率です。SLI が 0% なら機能はまったく動作しておらず、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 はアラートを出します。