fty-alert-list
Agent fty-alert-list serves as a broker between UI and fty-alert-engine. It also supports acknowledging alerts.
How to build
To build, run:
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=usr -DBUILD_TESTING=On ..
make
sudo make install
How to run
To run fty-alert-list project:
- from within the source tree, run:
./build/agent/fty-alert-list
For the other options available, refer to the manual page of fty-alert-list
- from an installed base, using systemd, run:
systemctl start fty-alert-list
Configuration file
Configuration file - fty-alert-list.cfg - is currently ignored.
Agent has an alerts state file stored in /var/lib/fty/fty-alert-list/state_file.
Architecture
Overview
fty-alert-list is composed of 1 actor and 1 timer:
- fty-alert-list-server: main actor
Timer in main() triggers cleanup of expired alerts out of alert cache every minute.
Protocols
Published metrics
Agent doesn't publish any metrics.
Published alerts
Agent publishes alerts on ALERTS stream.
Mailbox requests
Agent fty-alert-list-server can be requested for:
-
list of alerts of specified state
-
acknowledging an alert
List of alerts of specified state
The USER peer sends the following message using MAILBOX SEND to FTY-ALERT-LIST-SERVER ("fty-alert-list") peer:
- LIST/'state' - request list of alerts of specified 'state'
where
- '/' indicates a multipart string message
- 'state' MUST be one of [ ALL | ACTIVE | ACK-WIP | ACK-IGNORE | ACK-PAUSE | ACK-SILENCE ]
- subject of the message MUST be "rfc-alerts-list".
The FTY-ALERT-LIST-SERVER peer MUST respond with one of the messages back to USER peer using MAILBOX SEND.
- LIST/'state'/'alert_1'[/'alert_2']...[/'alert_N']
- ERROR/reason
where
- '/' indicates a multipart frame message
- 'state' is string and value MUST be repeated from request
- 'reason' is string detailing reason for error. If requested 'state' does not exist, the FTY-ALERT-LIST-SERVER peer MUST assign NOT_FOUND string as reason. If first frame of the message is not LIST, the FTY-ALERT-LIST-SERVER peer MUST assign BAD_COMMAND string as a reason.
- 'alert_X' is an encoded fty-proto ALERT message representing alert of requested state
- subject of the message MUST be "rfc-alerts-list".
A variant of the previous message with the same semantics is LIST_EX:
- LIST_EX/correlation_id/'state' - request list of alerts of specified 'state'
The FTY-ALERT-LIST-SERVER peer MUST respond with one of the messages back to USER peer using MAILBOX SEND.
- LIST_EX/correlation_id/'state'/'alert_1'[/'alert_2']...[/'alert_N']
- ERROR/correlation_id/reason
Acknowledging an alert
The USER peer sends the following messages using MAILBOX SEND to FTY-ALERT-LIST-SERVER ("fty-alert-list") peer:
- 'rule'/'asset'/'state'
where
- '/' indicates a multipart string message
- 'rule' MUST be name of the rule
- 'asset' MUST be name of the asset for which the rule exists
- 'state' must be one of the states ACTIVE, ACK-PAUSE, ACK-WIP, ACK-SILENCE, ACK-IGNORE
- subject of the message MUST be 'rfc-alerts-acknowledge'
The FTY-ALERT-LIST-SERVER peer MUST respond with one of the messages back to USER peer using MAILBOX SEND.
- OK/'rule'/'asset'/'state'
- ERROR/'reason'
where
- '/' indicates a multipart frame message
- 'rule', 'asset' and 'state' MUST be copied from request
- if FTY-ALERT-LIST-SERVER peer sends OK response, it MUST update the alert cache and republish the updated alert with recent timestamp
- 'reason' is string detailing reason for error. Possible values are: NOT_FOUND, BAD_MESSAGE, BAD_STATE
- subject of the message MUST be 'rfc-evaluator-rules'
Stream subscriptions
Agent is subscribed to _ALERTS_SYS stream and processes ALERT messages with state ACTIVE or RESOLVED. If new state means a change from ACTIVE to RESOLVED or vice versa, it updates the cache. If the stored state is one of the ACK states, it uses the cache to update the incoming alert. In both cases, alert is then republished on ALERTS stream.