Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Roadmap update for Pandora FMS 3.1 and 3.2

I've updated the roadmap for version 3.1 (Currently in development) and future version 3.2.

Changes are also written in our website at

As always, comments, suggestions and request are welcome.

Note that all features listed here are considered "Major features", there are lots of small features and improvmentes not listed here. Checkout our tracker to see that's is being done, and also our development blog.

Roadmap for Version 3.1 (May 2010)

Next version will be 3.1 and its planned to be released at May 2010. The features planned in this version are the following:

Service monitoring (Enterprise only)
Based on a group of different services/processes or another service(s); a service status will be obtained based on the sum of weights of warning/critical internal components. A service will be managed like another module, in reports, graphs and even alerts. This feature will be very useful to manage business processes and complex environments where a weight ponderation is needed.

Based on several opensource GIS components, Pandora FMS will display the GIS information of an agent, tracking its movement and getting the location of a new detected agent using the recon server. This will be implemented using only local servers, and will not need external web services like Google maps.

Full support for the network server of the advanced authentication characteristics of SNMP v3.

New enterprise ACL system
With this new ACL system (compatible with the standard ACL mechanism in Pandora since version 1.0), administrators will be able to segregate the console EVEN for itselfs, defining per user/page/option the permission level.

New reporting features
Several new reporting types will be added: Inventory reports, fully event, alert monitor listing, user-defined (SQL!) reports, data listing based on user-serialized format, and many more. We also included a new wizard (Enteprise only) feature to create massive reports (hundreds of elements) using a guided process to create large reports. Enteprise users will have also the possibility to define it's own cover page, headers, logos and personalized stuff in the report.

New visual console editor
A total rewrite of the visual console editor, much more visual and easy to use. Be able to copy visual maps, and edit them in a real WYSIWYG enviroment.

Pandora FMS metaconsole (Enteprise)
New system to have several independent Pandora FMS servers and be able to have a single, centralized way to manage and review information from all the managed Pandora FMS servers. This will allow to have a centralized user management, policies and module library.

More plugins for Pandora FMS Unix agents.
This will include an advanced and efficient way to get data on filesystems, system processes and opened ports.

(Provisional) Roadmap for version 3.2
Pandora FMS v3.2 will be released probably at the end of this year (2010), provisional date for release is November 2010 but probably will be delayed one or two months depending on the new features included in this version and not rated yet.

Synthethic modules
Able to get data from different existing modules, doing complex logical and arithmetic operations, in order to generate new data from the combination of single data.

Pandora FMS API improvement
Native integration (using web services) with Integria IMS for advanced incident management and Inventory tracking.

Scheduled Execution modules
It may define the implementation of certain modules (which will necessarily be asynchronous type), at certain times of day / week (similar to what do a cron).

This, together with a new system of user-definable timeout (to set the time in seconds the agent waits for the execution of a module), allowing Pandora FMS to work as a scheduler incorporated in the monitoring proccess.

Corrective actions in agents.
Implement corrective actions (command execution) at the agent, so that it can act after detecting an abnormal situation, as it operates now the watchdog of the Windows agent, but in a more open, where the user may specify function of a condition, the action to execute from the agent.

Communication between modules
The output of a module could be passed to the execution of another module. (To run a module based on the output above). This relationship will be 1-1, never being able to use multiple modules at once, and always done on past performance module.

Script/File Distribution to the agents
The agent may receive in a centralized way, a directory (containing subdirectories) with scripts and configuration files associated with these scripts, which will be copied to the installation directory of the agent.

The distribution of these scripts will be done centrally from the console, while the scripts associated with the policies.

Auto agent update.
Implement a system to update your own binary (. Exe or perl) agent running.

Multithreaded Agent for multiple concurrent asynchronous checks.
Creating an agent Unix threading in Perl, which supports parallel processing (number of threads defined by the user) of the modules for implementing monitoring, to perform several tests in parallel, this will prevent systems with large load monitoring agent "binding" of the monitoring process.

An improved error handling for the processing of each thread does not affect the agent, and that if execution of a module fails or hangs, does not affect the overall implementation of the agent.


Users browsing this thread: 1 Guest(s)

(c) 2006-2018 Artica Soluciones Tecnol├│gicas. Contents of this wiki are under Create Common Attribution v3 licence. | |

Theme © MyBB Themes