Events

Go back to Pandora FMS documentation index

Pandora FMS event system allows to see a real time record of all the events that take place in your monitored systems. The information displayed ranges from any module status change, alerts triggered or retrieved, to system restarts or custom events. By default, in the event view, a screenshot of what is happening at that time will be shown.

Events are classified by their severity:

• Maintenance (grey).
• Informational (blue).
• Normal (green).
• Warning (yellow).
• Critical (red).
• Major (brown).
• Minor (pink).

The following actions can be performed in regard to an event:

• Change its status (validated or in progress).
• Change the owner.
• Delete.
• Show additional information.
• Add a comment.
• Apply custom responses.

Events are managed in Events → View Events:

This is an example of the default event viewer:

From Pandora FMS version 726, you may sort out events by ID, status, name…

The event viewer shows shows a summary of each event and sometimes other associated data, such as the agent module that generated the event, the group, module-related tags, etc.).

By clicking on the magnifying glass, all event details are shown:

By default, events are shown through a specific search for the last 8 hours and for those that are not validated (and it can also be customized), in addition to grouping to avoid redundancy:

You may save searchers such as filters or either apply a previously created filter.

You may get more information in our video tutorial “Event management in Pandora FMS”.

Events are the record and a key point of a monitoring system.

An event may be in four different status:

• In process.
• New.
• Not validated.
• Validated.

When events take place due to module status changes, there will usually be two events: the first event is the change from normal to “faulty” state, and the second one is the event going back to normal once the problem is solved. In these cases, events going into a faulty state (critical or warning) are automatically validated when they go back to normal. This is what it is called event autovalidation and it is an extremely useful feature.

When working manually, an event can be validated. That will make the system save the date and the user who validated the event. It is also possible to leave a comment:

By clicking on the validate button, the screen is refreshed and the validated event “disappears”.

Un event can be checked as “in process” in the Responses tab:

That way the event will not get auto-validated and will stay as pendant. Notice the possible actions: execute custom responses such as pinging the host or assigning to name a couple of them.

You may validate, check as “in process” or delete events individually by clicking on the corresponding icons:

Or mass apply them to a selection:

Important aspects of this feature:

• Filters can be saved to be used again later on.
• The limit for old events (Max. hours old) can be customized.
• Pandora FMS, by default, groups repeated events (Duplicate → Group events), however this preference can be changed:
  • All events: Display all events individually.
  • Group agents: Group events by agent.
  • Group events: The event name, agent ID and module ID are used to identify duplicates.
  • Group Extra IDs: Events will be grouped by Extra ID only, sorted by Timestamp.
• You may filter by specific group. If you use the Group recursion option, it will also search in the subgroups of that group. Likewise, if you select Search in secondary groups, the events of agents with assigned secondary groups will be included.These last two options may imply some work impact on PFMS server.

• You can request the events during a specific time lapse using the From (date) and To (date) fields.
• You can filter by custom fields using Custom data filter, either by filtering the field name (Filter custom data by field name) or by custom field content (Filter custom data by field value). These custom fields will be displayed as columns in the event view.

The event filters that you consider most frequently used can be added to the Events section in the Favorite menu (Operation menu). This is done by clicking on the star icon that will appear when loading a saved filter (Current filter). Clicking it again allows you to uncheck the icon and remove it from the favorites system.

Events can be deleted individually and/or automatically.

There is also the possibility in the , to keep them in order to create special reports.

Individually:

Automatic event purging:

Event history

To see events in a news channel or RSS go to Events > RSS and subscribe from the news reader of your choice.

It allows to spread the sound alerts when an event takes place. The tune will be played until you pause the sound event or press the OK button.

The list of sound events that generate a sound alert by default (and may be customized) is:

• A triggered alert.
• A module going into warning state.
• A module going into critical state.
• A module going into unknown state.

Go to Operation → Events → Acoustic console.

This action opens a popup window control for all sound events. This example uses Google Chrome, you must configurate it to let popup windows open.

Sound events are explored every 10 seconds asynchronously, when an event takes place, the window will start blinking in red or vibrating and in addition, depending on the configuration of your browser or operative system, the window will keep the focus and stay over the rest of the open windows.

To add new tunes, copy said files in WAV format, to the directory:

/var/www/pandora_console/include/sounds/

keep in mind that each tune must be sent to the browser and takes some bandwidth; it is recommended:

• Select an audio file only a few seconds long as the main alert sound, because it will be played on loop.
• Convert the audio to mono.
• Change the audio's coding to 16bits signed or even less. Quality will be lost but the file's size will decrease by doing this.
• In order to create or edit audio files, it is recommended to use tools as Audacity.

In order to export the events to a CSV file, click on Operation → View Events and Export to CSV File.

To access event statistics go to Events> Statistics.

Event graph

Event percentage according to their status.

Event graph by user

Percentage grouped by user.

Event graph by agent

Percentage by agent generated by each event.

Number of validated events

Validated events and to-be-validated.

When clicking on any of the sections, detailed information will appear.

For Pandora FMS release 741 onwards, there is event related alert management, a specific wiki section.

Pandora FMS external API is used making remote calls (through HTTPS) on the /include/api.php file. This is the method defined in Pandora FMS to integrate third party applications. It basically consists of a call with the parameters formatted to receive a value or a list of values that this application will use to carry out operations.

By using the WEB API, you may interact with Pandora FMS from any remote system, even if you do not have connection to the database with an installed Software agent.

The three main points to activate Pandora FMS API:

1. Enable the API access for the IP from wich the command will be executed or use '*' for all IPs.
2. Set an API password
3. Use a user/password to login, or define a specific user to access it through API.

The password devoted to creating or validating events through Pandora FMS API may be copied from:

/usr/share/pandora_server/util/pandora_revent.pl

When executed in the client device, without parameters, you may see its syntax (here translated):

Pandora FMS Remote Event Tool Copyright (c) 2013 Artica ST
This program is Free Software, licensed under the terms of GPL License v2
You can download latest versions and documentation at https://www.pandorafms.org

Options to create event:

  ./pandora_revent.pl -p <path_consoleAPI> -u <credentials> -create_event <opts>

Where the options are:

 -u <credentials>:
     API credentials separated by comma: <api_pass>,<user_name>,<user_pass>
 -name <event_name>:
   Free text
 -group <id_group>:
   Group identifier (use 0 for 'all')
 -agent:
   Specify agent by identifier.

Optional parameters:

 [-status <status>]  : 0 New, 1 Validated, 2 In process
 [-user <id_user>]   : Comment user (combine with -comment)
 [-type <event_type>] : unknown, alert_fired, alert_recovered, alert_ceased
         alert_manual_validation, system, error, new_agent
         configuration_change, going_unknown, going_down_critical,
         going_down_warning, going_up_normal
 [-severity <severity>] :
        0 Maintenance,
        1 Informative,
        2 Normal,
        3 Warning,
        4 Critical,
        5 Minor,
        6 Major.
 [-am <id_agent_module>]       : ID del modulo de agente origen del evento
 [-alert <id_alert_am>]        : ID de la alerta/modulo origen del evento
 [-c_instructions <critical_instructions>]
 [-w_instructions <warning_instructions>]
 [-u_instructions <unknown_instructions>]
 [-user_comment <comment>]
 [-owner_user <owner event>]   : Event proprietary, use login name
 [-source <source>]            : ('Pandora' by default)
 [-tag <tags>]                 : Tag (must already exist in the system)
 [-custom_data <custom_data>]  : Custom data must be a 64 base
                                 encoded JSON document (>=6.0)
 [-server_id <server_id>]      : Server node ID (>=6.0)
        [-id_extra <id extra>] : Extra ID
 [-agent_name <Agent name>]    : Agent name, do not mistake with alias.
 [-force_create_agent<0 o 1>]  : It forces agent creation if it does not exist that
                                 is why the parameter is 1 and it must have the option
                                 agent_name.

Example of event generation, using \ as order connector and didactic indenting:

 ./pandora_revent.pl \
      -p https://$path_consoleAPI/pandora_console/include/api.php \
      -u $api_pass, $user_name, $user_pass \
      -create_event \
                    -name "SampleEvent" \
                    -group 2 -agent 189 \
                    -status 0 \
                    -user "admin" -type "system" \
                    -severity 3 \
                    -am 0 \
                    -alert 9 \
                    -c_instructions "Critical instructions" \
                    -w_instructions "Warning instructions"

Options to validate an event:

./pandora_revent.pl -p <path_to_consoleAPI> -u <credentials> -validate_event <options> -id <id_event>

Sample of event validation:

 ./pandora_revent.pl \
     -p https://$path_consoleAPI/pandora/include/api.php \
     -u $api_pass, $user_name, $user_pass \
     -validate_event \
                    -id 234

It is the same feature as the 'pandora_revent' script with the exception of not being able to validate events. You may do it using the tool found at:

/usr/share/pandora_server/util/pandora_revent_create.pl

This tool uses an HTTP/HTTPS remote connection to create or validate events under Pandora FMS. Execute it without parameters to see the syntax here translated:

Pandora FMS Remote Event Tool Copyright (c) 2013 Artica ST
This program is Free Software, licensed under the terms of GPL License v2
You can download latest versions and documentation at http://www.pandorafms.org

Options to create event:

    ./pandora_revent_create.pl -p <path_to_consoleAPI> -u <credentials> -create_event <options>

Where options:

    -u <credentials>            : API credentials separated by comma: <api_pass>,<user>,<pass>
    -name <event_name>            : Free text
    -group <id_group>            : Group ID (use 0 for 'all')
    -agent                    : Agent ID

Optional parameters:

    [-status <status>]            : 0 New, 1 Validated, 2 In process
    [-user <id_user>]            : User comment (use in combination with -comment option)
    [-type <event_type>]            : unknown, alert_fired, alert_recovered, alert_ceased
                              alert_manual_validation, system, error, new_agent
                              configuration_change, going_unknown, going_down_critical,
                              going_down_warning, going_up_normal
    [-severity <severity>]         : 0 Maintance,
                          1 Informative,
                          2 Normal,
                          3 Warning,
                          4 Crit,
                          5 Minor,
                          6 Major
    [-am <id_agent_module>]        : ID Agent Module linked to event
    [-alert <id_alert_am>]            : ID Alert Module linked to event
    [-c_instructions <critical_instructions>]
    [-w_instructions <warning_instructions>]
    [-u_instructions <unknown_instructions>]
    [-user_comment <comment>]
    [-owner_user <owner event>]        : Use the login name, not the descriptive
    [-source <source>]            : (By default 'Pandora')
    [-tag <tags>]                : Tag (must exist in the system to be imported)
    [-custom_data <custom_data>]        : Custom data should be a base 64 encoded JSON document (>=6.0)
    [-server_id <server_id>]        : The pandora node server_id (>=6.0)

Example of event generation:

    ./pandora_revent_create.pl -p http://localhost/pandora_console/include/api.php -u 1234,admin,pandora
        -create_event -name "SampleEvent" -group 2 -agent 189 -status 0 -user "admin" -type "system"
        -severity 3 -am 0 -alert 9 -c_instructions "Critical instructions" -w_instructions "Warning instructions"

Enable the API access and configure it first. Follow these three steps to do so:

1. Enable the API access for the IP from which the command will be executed or use '*' for all IPs.
2. Set an API password.
3. Use a regular user/password or define a specific user to have access through the API.

In order for the 'unknown', 'critical' or 'warning' instruction fields to appear within the event details, the event type is required to be 'going_unknown', 'going_down_critical' or 'going_down_warning'.

More examples:

/pandora_revent_create.pl -p http://192.168.50.12/pandora_console/include/api.php -u pandora12,admin,pandora
-create_event -name "Another nice event" -group 0 -type "system" -status 0 -severity 4
-user "davidv" -owner_user "admin" -source "Commandline" -comment "Prueba de comentario"

Events with custom fields may be generated by the Pandora FMS CLI, e.g. An event generated by the following command:

perl pandora_manage.pl /etc/pandora/pandora_server.conf --create_event 'Custom event' system Firewalls 'localhost' 'module' 0 4 // 'admin' // // // // '{"Location": "Office", "Priority": 42}'

It would look like the one shown below.

In the Event section in the management part of Pandora FMS console('Events' > 'View events' > 'Manage events'), the following aspects regarding events can be configured:

• Event filtering.
• Event responses.
• Event display.

It is possible to customize the fields that the Event View shows by default from the ►Events → View events, click on Manage events → Custom columns section, where the fields to be shown can be chosen.

You may also access this section from Management → Configuration → Events → Custom columns.

By default, the fields displayed are:

• Severity mini: Event severity in reduced format.
• Event name: Event name.
• Agent ID: Agent ID.
• Status: Event status.
• Timestamp: Date when the event was created.

However, there is a great number of fields apart from those shown by default that can be added to the Fields selected list:

• Event ID: Event ID.
• Agent name: Agent name.
• User: Event creator user.
• Group: Group the module belongs to.
• Event type: Event type.
• Module name: Module name.
• Alert: Alert linked to the event.
• Severity: Event severity.
• Comment: Event comments.
• Tags: Module tags.
• Source: Event source.
• Extra ID: Extra ID.
• Owner: Owner.
• ACK Timestamp: Date when the event was validated.
• Instructions: Critical or warning instructions.
• Server name: Name of the server the event came from.
• Data: Numerical data reported by the event.
• Module status: Module current status.
• Module custom ID: Value of the Module custom Module ID field

Select the fields you wish to display from the Fields available list and move them to Fields selected using the horizontal arrows.

• When you select a field in Fields selected, you may move its location up or down using the vertical arrows to the right of the list.
• By clicking on the icon you can restore the fields to how they were before starting modifying them.

Once selected, click Update.

In this section you may create, remove and edit filters applied to the event view.

By clicking on Create new filter, the following view is shown, where the fields by wich you wish to filter may be chosen.

Once the filters have been saved, right from the Event View itself they can be loaded to display the desired information quickly without having to reconfigure the filter each time:

In this section, event responses can be created, edited and deleted. An event response is a custom action that can be executed on an event, for example, creating a ticket in Integria IMS with the relevant information about the event. More information about Integria IMS can be found in Pandora FMS documentation.

Enter a representative name, a description, the parameters to use, separated by commas, the command to use (the last ones allow the use of macros), the type and the server that will execute the command.

In Parameters you may enter as many as you need, separated by commas. When you make the response, a dialog box will appear to fill in each one of them and add it to the event.

The accepted macros are:

Agent address.

Agent alias.

Agent ID.

Agent name.

Event related alert ID.

Command response time (seconds).

Id of the user who executes the response.

Full name of the user executing the response.

Pulls all information from custom data in JSON format.

Pulls all information from custom data in text mode (with carrier return).

Pulls a particular field from custom data, replacing the X with the field's name.

Date on which the event took place.

Extra event ID.

Event ID.

Event instructions.

Event severity ID.

Event severity (translated by Pandora FMS console).

Event source.

Event status (new, validated or event in process).

Event tags separated by commas.

Full text of the event.

Event type (System, going into Unknown Status…).

Date on which the event occurred in utimestamp format.

Group ID.

Group name in database.

Contact information for a group of agents.

Event associated module address.

Event associated module ID.

Event associated module name.

For Metaconsole and Node, returns the node identifier.

For Metaconsole and Node, returns the node name.

Event owner user.

Full name of the user who owns the event.

User ID.

Go back to Pandora FMS documentation index