Automation of decision making for monitoring systems

1. Automation of decision making for monitoring systems Włodzimierz Funika, Filip Szura

2. Motivation • Main issue • Automation of Network monitoring • Rules • Understandable • Easy to create • External Engine (Jboss Drools) • Usage of external monitoring systems • Extension of existing solutions (Zabbix) • Actions described as: • Java code • Unix action scripts

3. System architecture System dividedintothree components: • Server • Decision component • Local-Monitor • Data collector • GUI • Presentation Network 1, 2 – monitored networks RMI (Remote Method Invocation) – standard communication between system components

4. System architecture • Saude-Net GUI • Configuration provided during work by the user • Web page generation, communication over RMI • Saude-Net Server • Configuration stored in XML • Rules stored in DRL file • Rules engine • Saude-Net Local-Monitor • Dependent on external monitoring system • XML configuration • Connection over RMI • No actions provided for user during work

5. System details Saude-Net(System for automation of decision making for monitoring systems) • Designed for small and medium size networks • Multiple actions for resources under monitoring • Fully configurable • Rule and actions management is easy for network administrator • System choose the best action when event occurred in the monitored network • Can manage multiple networks

6. Demo GUI component Trigger the best action List of availableactions Saude-Net Server KnowledgeEngine Saude-NetLocal-Monitor Monitoring Tool (Zabbix) Data From Monitoring Tools

7. System details • Preference tuning value (PTV) • Preference value (PV) Ns - number of services which are currently modified D - number of instances of any action Iw - sum of instances of a specifed action as the best (+1) and other (-1) PV = oldPV + PTV

8. System features • Classic monitoring systems • Network events are reported to network administrator • Our solution • System automatically react on reported failures • Reaction based on actual network snap-shot and knowledge • In effect, system is able to perform any action when network event occurred • Action described as Unix action script • Short Java script located in rule

9. Implementation • Server component • Calculating preferences for actions • Invoke actions • Stores actual view of network and actual knowledge base • Validation of rules • Local-Monitor component • Acquiring data from external monitoring systems (Zabbix) • Sending data to Saude-Net server • Presentation component • Extension of Local-Monitor • Simple simulator of network • GUI component • Create rules • Simple validation • Data representation • Form generation

10. Implementation • Used technologies: • Java – available for most operating systems, the same data representation in different systems • JSF – less code than in JSP • Jboss Drools – easy to use, available for java • XML – required by Spring • Spring Framework – allows for Dependency Injection, provides a connection to database • Component architecture • System divided into separate components • Web-based GUI • System management by web pages

11. Conclusions • Achievements • Automatic actions on network failures • Actions described by rules • Easy configuration of rules and actions • Distributed architecture • Limitations • All components must be implemented in Java • Configuration may not be changed during system work • Rules are created only by administrator, our system is not allowed to create its own rules. • Future work • System should learn automatically from actions taken by the administrator • Extensions of Saude-Net system security • Redundancy of Saude-Net server component

12. More details • Poster number: 6

13. Thank you for your attention!