Skip to content

Alerting Architecture

Alerting is the tenant-specific evaluation layer that turns collected CPI and keystore runtime data into actionable alert records. It sits between background collection and operational review.

Functional role

The current CPI-oriented alert engine mainly monitors:

  • message processing failures or patterns
  • iFlow and artifact deployment status
  • keystore and certificate validity conditions
  • daily checks for iFlows without expected messages

Persistence model

Alert configuration is primarily stored in cConfigExt:

  • name = "jobs.alerts"
  • data_type = "config"

Alert runtime state also lives in cConfigExt:

  • name = "jobs.alerts"
  • data_type = "runtime"

Triggered alert records are persisted in cpiAlert and linked through object-specific relation tables such as:

  • cpiMessageAlert
  • cpiFlowAlert
  • cpiKeystoreEntryAlert

Runtime boundary

flowchart LR
    CFG[cConfigExt jobs.alerts.config and runtime] --> TASK[task_alerts.py]
    MSGDATA[cpiMessageLog and related runtime tables] --> MSG[alerts_message.py]
    FLOWDATA[cpiFlow and package state] --> FLOW[alerts_iflow.py]
    KEYDATA[cpiKeystoreEntry] --> KEY[alerts_keystore.py]
    TASK --> MSG[alerts_message.py]
    TASK --> FLOW[alerts_iflow.py]
    TASK --> KEY[alerts_keystore.py]
    TASK --> DAILY[alerts_iflow_no_messages.py]
    DAILY --> FLOWDATA
    MSG --> ALERT[cpiAlert]
    FLOW --> ALERT
    KEY --> ALERT
    DAILY --> ALERT
    ALERT --> UI[AlertPopup and overview cards]
    UI --> ACK[acknowledge and suppress actions]

Dependency map

Alerting does not create its own source truth for operational facts. It depends on earlier runtime collection:

  • message alerts depend on synchronized message data
  • iFlow alerts depend on flow and deployment state
  • keystore alerts depend on synchronized certificate inventory
  • the UI depends on persisted alert rows rather than recalculating conditions on demand

Important distinction

backend/src/core/models.py still contains a more generic alert model layer with cAlertType and cAlert. The operational CPI alert flow currently depends instead on:

  • jobs.alerts.config
  • jobs.alerts.runtime
  • cpiAlert and its link tables

That distinction matters whenever new alert requirements are implemented.