Skip to main content
Use a custom Pandora FMS alert command to send module alert triggers and recoveries to Flashduty On-call. Each Pandora FMS module alert maps to one Flashduty alert: the alert triggers when the module alert fires, repeated firings merge into the same alert, and the alert recovers when the module no longer meets the alert template’s condition.

​
In Flashduty On-call

You can get the integration push URL in either of the following ways.

​
Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Pandora FMS and click Save
  4. Open the new integration card and copy the push URL

​
Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Pandora FMS and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routes after creation
  4. Click Save and copy the generated push URL

​
Configure Pandora FMS

Pandora FMS alert actions run a command on the Pandora FMS server. The steps below create an alert command that pushes with curl, create an action that uses the command, and then add the action to module alerts.
The Pandora FMS server that executes alerts needs curl installed and HTTPS access to the domain in the push URL.
1

Create the alert command

  1. Sign in to the Pandora FMS console as an administrator, go to Management → Alerts → Commands, and click Create
  2. Set Name to Flashduty
  3. Set Command to the command below. Keep it on one line and do not rename the fields:
  1. Fill in the field descriptions and values as follows:
  1. Click Create to save
Every macro sits inside double quotes. Pandora FMS shell-quotes the value when it replaces the macro, and curl --data-urlencode then URL-encodes it, so spaces, quotes, and non-ASCII text in agent names or module descriptions reach Flashduty unchanged.
2

Create the alert action

  1. Go to Management → Alerts → Actions and click Create
  2. Set Name to Flashduty, set Group to the groups that should use the action (All for every group), and set Command to the Flashduty command from the previous step
  3. Fill in the fields as follows. Fill in both the Triggering and Recovery columns:
  1. Click Create to save
3

Make sure the alert template has recovery enabled

Go to Management → Alerts → Templates, open the template you use, and in step 3 Advanced fields make sure Alert recovery is enabled. The built-in Critical condition and Warning condition templates have it enabled by default. With Alert recovery disabled, Pandora FMS runs no action when the module recovers, and the Flashduty alert does not close automatically.
4

Add the action to module alerts

  1. Go to Management → Alerts → List of Alerts and click Create to create a module alert, or find an existing one in the list
  2. Select the Agent, Module, and Template, and select Flashduty under Actions
  3. Click Add alert
You can also add an alert for a module from the agent’s Alerts tab and select the Flashduty action. For an existing module alert, just add the Flashduty action; existing actions such as email are not affected.
5

Verify the lifecycle

Put a module that has an alert into its alert condition (for example, lower the Critical threshold of a CPU module) and confirm that Flashduty receives an active alert. Restore the threshold, wait for the next data collection, and confirm that the alert closes.
The action’s Field 2 must be alert_recovered in the Recovery column. If the Recovery column is empty, Pandora FMS falls back to the alert template’s recovery field (the built-in templates’ Field 2 recovery value is an email subject), Flashduty rejects that recovery as a parameter error, and the alert does not close.

​
Pushed content

The command POSTs the following fields as an application/x-www-form-urlencoded form: The alert title is <template name>: <agent> / <module>. When some fields are missing the rest are used, and when all are empty the title is Pandora FMS alert <id_alert>.

​
Alert Key

Flashduty uses id_alert (the Pandora FMS macro _id_alert_) as the Alert Key. The Pandora FMS documentation describes this macro as “Alert identifier, useful for correlating the alert in third-party tools”: it is the ID of the module alert created when a template is assigned to a module. The trigger, repeated firings, and recovery of one module alert carry the same ID, so they land on the same Flashduty alert. One template assigned to two modules makes two module alerts with different IDs, which produce different Flashduty alerts. Changing the template name, priority, agent alias, or data does not change the Alert Key. Module alert IDs are unique only within one Pandora FMS installation. Use a separate Flashduty integration for each installation (including each node under a Metaconsole), so that alerts with the same ID in different installations do not merge into one alert. Only module alerts carry _id_alert_. Event alerts, log alerts, and correlated alerts have no module alert ID and Flashduty rejects them as a parameter error, so do not add the Flashduty action to them.

​
Status and severity

event decides whether the alert triggers or recovers, and alert_priority (the alert template’s Priority) decides the severity: When event is alert_recovered the alert recovers, and its severity still comes from the template priority. Requests with an empty or any other event are rejected, so a request whose state cannot be determined never enters the wrong alert lifecycle.

​
FAQ

Pandora FMS runs the same action when an alert fires and when it recovers, and no macro tells which one it is. Only action fields can take separate Triggering and Recovery values, so alert_fired and alert_recovered in Field 2 tell Flashduty whether the run is a trigger or a recovery.
Forcing a module alert that has not fired sends alert_times_fired 0. Flashduty treats such a request as a test, returns success, and creates no alert. Forcing an alert that has already fired merges into that alert and does not create a new one.
No. Repeated firings of one module alert before it recovers carry the same id_alert and merge into the same Flashduty alert. How often it fires again is controlled by the template’s Max number of alerts and the action’s Threshold.
Check, in order: the alert template has Alert recovery enabled; the action’s Field 2 is alert_recovered in the Recovery column; the module alert is not in Standby (alerts in Standby run no actions).

​
Troubleshooting

  • Pandora FMS does not push: run curl -sS <push URL> on the Pandora FMS server to confirm the network path, and make sure the action’s Group covers the agent’s group
  • Flashduty returns a parameter error: make sure the command is pasted in full on one line, the action’s Field 2 is alert_fired and alert_recovered in the two columns, and the action is only added to module alerts
  • The alert does not recover: see the FAQ “The alert recovered in Pandora FMS but did not close in Flashduty?” above
For macros and alert configuration, see the Pandora FMS documentation Alerts.