ワークスペースアラート

ワークスペース管理者は、次からアラートを設定できます。 システム設定 → ワークスペースアラート。管理者が宛先を保存して有効にするまで、通知はオフになります。各ワークスペースには独自の宛先とインシデント履歴があります。

JSON POST リクエストを受け入れるパブリック HTTPS エンドポイントを使用します。プライベート/ローカル アドレス、リダイレクト、埋め込みユーザー名/パスワード、および URL フラグメントは拒否されます。 SubLane は宛先を暗号化し、そのホストのみを表示し、自動的に公開することはありません。 URL を保持するには、編集時に空白のままにしておきます。宛先を削除すると、通知が無効になり、保留中の通知履歴が削除されます。

条件

チェックでは、ローカルの永続状態が約 1 分に 1 回使用されます。モデルリクエストやテストサブスクリプション認証情報は送信しません。元のプール アラートはアカウントの健全性をチェックします。必要に応じて、モデル アラートを有効にし、使用済みクォータのしきい値を 1 ～ 99 で構成します (空白の場合は無効になります)。デフォルトでは両方ともオフになっています。許可され、以前に観察されたモデルと新しいクォータのみが評価されます。未知の観測や古い観測では、障害や回復を証明することはできません。同時実行の飽和だけではモデル アラートはトリガーされません。アイドル状態のスナップショットは期限切れになる可能性があり、チェックではメタデータが更新されません。リクエストが成功した後のクールダウンをクリアするか、管理者の回復アクションにより、プールのインシデントを解決できます。

配送と回収

変更されていないインシデントは 1 つの通知を送信します。発生イベントが受け入れられた後に条件がクリアされると、 resolved イベント。インシデント状態は再起動後も存続します。配信失敗の場合は 1 分後に再試行され、最大 30 分までバックオフされます。各パスでは、インスタンス全体で最大 10 回の配信が試行されます。保留中のキューが大きい場合は、追加のパスが必要になる場合があります。

受信機は 5 秒以内に 2xx ステータスを返さなければなりません。を使用して重複を排除します id、でも送信されます。 Idempotency-Key ヘッダー: 確認応答の損失、または受信者の受け入れとローカル永続性の間の再起動により、配信が繰り返される可能性があります。設定を保存してもテストは送信されません。宛先を保存した後、明示的に テスト通知を送信する通知をオフにしても。その kind そして status は test。再起動後は 1 分あたり 1 回のテストが許可されます。失敗は再試行されず、インシデントの状態は変更されません。設定ページには、配信失敗と最後に受け付けられた通知時間が表示されます。 URL を保存するだけでは、それが機能することは証明されません。

合成 ID を使用したイベントの例:

{
  "id": "11111111111111111111111111111111",
  "workspace_id": 1,
  "kind": "pool_unavailable",
  "subject": "2",
  "status": "firing",
  "observed_at": 1900000000
}

モデルイベントの使用 model_unavailable、プール ID とネイティブ モデル ID が件名としてコロンで結合されています。クォータイベントの使用 quota_low、件名としてアカウント ID を指定します。

識別子 (モデル イベントのネイティブ モデル ID を含む)、条件タイプ、状態、および観測時間のみが送信されます。アカウント名、メンバー ID、キー、Webhook URL、プロンプト、応答、生のエラーは除外されます。これは一般的な Webhook 形式です。チャット アプリケーションでは、メッセージ形式へのアダプターが必要な場合があります。

バックアップには、暗号化された宛先と、一致するボールト キーを使用したインシデント履歴が含まれます。古いスナップショットを復元すると、後続のインシデントが再現される可能性があるため、受信者は重複排除履歴を保存する必要があります。