アラームとイベントのライフサイクル

Edge-EMS Builder は個別のアラームレコードと、復旧フローを持つアラームイベントの両方に対応します。継続監視ルールを新規作成する場合、アラームイベントで「異常発生、復旧、手動解決」の全過程を追跡できます。

2 種類のアラーム方式

方式	適した用途	動作
アラームレコード	簡易通知、各発生結果の保存	アクションごとに個別レコードを生成し、処理済みとしてマーク可能
アラームイベント	継続的な障害監視と対応追跡	同じ発生元とアラーム識別子をまとめ、発生回数と状態変化を記録

既存のスクリプトは引き続き使用できます。既存のアラームレコードが自動的にアラームイベントへ変換されることはありません。

イベントの状態

異常発生中（ACTIVE） → 復旧済み（RECOVERED） → 解決済み（RESOLVED）

• 繰り返す異常は同じ未解決イベントへ統合し、初回と直近の発生時刻を保持します。
• 正常な観測により「復旧済み」へ移行し、オペレーターまたは管理者が解決を確認します。
• 復旧後に再び異常が発生すると、同じイベントを再有効化します。解決後に再発した場合は、新しいイベントを作成します。
• デバイスのオフラインや無効なデータは「不明」であり、復旧と誤判定しません。

観測アクションの設定

アラームは安定した sourceCode + alarmKey で識別します。ルールは異常、正常、不明を継続的に報告する必要があります。異常時だけ実行すると、システムは復旧時点を把握できません。

以下は汎用ポイント demo_temperature の例です。使用前に実際のポイントへ置き換え、適切な監視周期を設定してください。

local value = tonumber(${demo_temperature})
local state = "UNKNOWN"
if value then
  if value > 80 then state = "ACTIVE" else state = "NORMAL" end
end
return {buildAlarmObservationMap("demo_monitor", "demo_temperature_high",
  state, "高温", "1", "温度状态：" .. tostring(value))}

このスクリプトは EXPRESSION トリガーアクションで使用します。アラーム識別子に現在の温度やタイムスタンプを含めると、観測のたびに別のイベントが生成されるため避けてください。

照会と対応

発生元、種類、レベル、状態、時間範囲でイベントを絞り込み、発生回数、復旧時刻、解決説明を確認できます。手動解決にはイベントの最新バージョン番号を使用し、複数人による操作の上書きを防ぎます。デバイスやルールを正式に廃止した場合、管理者は理由を記録して対応するイベントを廃止できます。

クラウドへの通知が必要な場合は、MQTT で別途送信を設定できます。スクリプトと API の使い方は Lua リファレンス と アラーム Skill を参照してください。