コンテンツにスキップ
NBS Workshop

Alert Monitor

役割

Alert Monitor は BWTS IOT パイプラインの常時稼働の見張り役です。スケジュールされたルーチン(cron)で動作し、2つの入力チャネルを継続的にスキャンして新規アラートを探します。見つけ次第、アラートを構造化ペイロードにパッケージして IOT Manager に手渡します — それ以上のことはしません。

二重発見

Alert Monitor は2つの発見経路を並列で実行し、3つ目をフォールバックとして持ちます。これにより、アラートがシステムに入る経路を問わず、見落としが起きないことを保証します。

graph LR
    subgraph "Parallel Discovery"
        direction TB
        A["Path A\nEmail (IMAP)\ngmail_fetch.py"]
        B["Path B\nDashboard API\n/api/alert-instances"]
    end


    subgraph "Fallback"
        C["Path C\nDB Query\ndb_query.py"]
    end


    A -->|"BWTS-IDs from subject lines"| MERGE["Merge & Deduplicate"]
    B -->|"Pending alerts from API"| MERGE
    C -.->|"Only if A+B return empty"| MERGE


    MERGE --> ENRICH["Fetch Full Unresolved Context\nfrom Dashboard API"]
    ENRICH --> TASK["Create Task\nfor IOT Manager"]


    style A fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style B fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style C fill:#0d1b2a,stroke:#e94560,stroke-width:1px,color:#fff
    style MERGE fill:#1a1a2e,stroke:#e94560,stroke-width:2px,color:#fff
    style ENRICH fill:#1a1a2e,stroke:#0f3460,stroke-width:2px,color:#fff
    style TASK fill:#1a1a2e,stroke:#e94560,stroke-width:3px,color:#fff

gmail_fetch.py を使用して、IMAP 経由でモニタリング対象の受信箱に接続します。未読メッセージから BWTS アラート・パターンを含む件名をスキャンします。件名と本文から機器IDとアラート・メタデータを抽出します。

強み: クルーや第三者のモニタリング・システムから転送され、ダッシュボードに届かない可能性のあるアラートを補足できます。

仕組み

  1. 受信箱をポーリング

    スケジュールされたルーチンが gmail_fetch.py をトリガーします。設定済み IMAP メールボックスに接続し、BWTS アラート・パターンに一致する未読メール(件名にアラート・キーワードまたは既知の送信元アドレスを含む)を取得します。

  2. 件名から BWTS-ID を抽出

    一致した各メールについて、モニタは件名行をパースして BWTS 機器識別子(例:BWTS-UV-003)とアラート種別を抽出します。メール本文は補助フィールド用にスキャンされますが、一次データソースとしては扱われません。

  3. 保留アラートのため API を呼ぶ

    メールスキャンと並行して、モニタは Dashboard API を呼び出します:

    GET https://bwts-iot.vercel.app/api/alert-instances

    これは、完全な構造化データを持つ、現在未解決のアラート・インスタンスをすべて返します。

  4. マージと重複除去

    Path A(メール)と Path B(API)の結果がマージされます。重複除去は 機器タグ + アラートコード + タイムスタンプ窓(5分以内は同一アラートとみなす)の組み合わせを使用します。両経路がゼロ結果を返した場合、Path C(DB フォールバック)が起動されます。

  5. 完全な未解決文脈を取得

    各ユニークなアラートについて、モニタは Dashboard API を再度呼び出し、完全な未解決文脈 — 現在のセンサー値、しきい値設定、アラート重大度を含む — を取得します。このエンリッチメント・ステップにより、下流ペイロードが自己完結的になることが保証されます。

  6. IOT Manager 向けタスクを作成

    モニタは IOT Manager に割り当てられた LifeOSAI タスクを作成し、構造化された alert_monitor_v1 ペイロードを含めます。ユニークなアラート1件につきタスク1つです。

  7. メールを処理済みとマーク

    一致したメールはすべて既読としてマークされる(または「処理済み」フォルダに移動される)ことで、次回のポーリングサイクルでの重複処理を防ぎます。

重要原則

出力形式

IOT Manager 向けに作成されるすべてのタスクは、alert_monitor_v1 スキーマに従います。ペイロードには、マネージャーがフェーズ1の専門家を派遣するために必要なすべての情報が含まれます。

フィールド型説明
schema_versionstring常に "alert_monitor_v1"
alert_instance_idstringDashboard API からのユニーク識別子
equipment_tagstringBWTS 機器識別子(例:BWTS-UV-003)
vessel_namestring機器が設置されている船舶の名前
alert_codestring標準化されたアラームコード(例:HIGH_UV_INTENSITY)
alert_severitystringCRITICAL、WARNING、INFO のいずれか
parameter_namestring違反している具体的なセンサーパラメータ
current_valuenumberアラートをトリガーしたセンサー読み値
threshold_valuenumber違反された設定済みしきい値
threshold_directionstring"above" または "below" — 違反方向を示す
triggered_atstring (ISO 8601)アラートが最初にトリガーされたタイムスタンプ
source_pathstringこのアラートを発見した経路:"email"、"api"、または "db_fallback"
raw_email_subjectstring | nullPath A 経由で発見された場合は元のメール件名、それ以外は null
unresolved_contextobjectDashboard API エンリッチメント・ステップからの完全な文脈オブジェクト

してはならないこと

分析しない

アラート重大度を解釈しない、過去データと相関させない、根本原因を推測しない。

根本原因の仕事はしない

機器マニュアル、保全記録、過去ケースファイルを問い合わせない。それは専門家の仕事。

レポートしない

関係者にメールを送信しない、HTML レポートを生成しない、エンドユーザーに所見を伝達しない。

ツール

ツールスクリプト / エンドポイント目的
Email (IMAP)gmail_fetch.pyモニタリング対象メールボックスに接続、未読の BWTS アラートメールを取得、処理済みとマーク
Dashboard API/api/alert-instances完全な構造化文脈を持つ保留/未解決のアラート・インスタンスを取得
DB フォールバックdb_query.pyメールと API の両方がゼロ結果を返したときの直接DBクエリ
Task SystemLifeOSAI task creationalert_monitor_v1 ペイロードで IOT Manager 向け構造化タスクを作成

スケジューリング

Alert Monitor はスケジュールされたルーチン(cron)として動作します。推奨ポーリング間隔は運用文脈に依存します:

環境間隔根拠
本番(航海中)5分ごと運転中のアラート対応レイテンシを最小化
本番(港内 / アイドル)15分ごと緊急性低下、API 負荷を削減
開発 / テストオンデマンドパイプラインを端から端までテストするため手動トリガー