Transcript System for automation of decision making for monitoring systems

Automation of decision making for
monitoring systems
Włodzimierz Funika, Filip Szura
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
System architecture
System divided into three
components:
 Server
 Decision component
 Local-Monitor
 Data collector
 GUI
 Presentation
Network 1, 2 – monitored
networks
RMI (Remote Method Invocation)
– standard communication between system components
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
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
Demo
GUI component
Trigger the best
action
List of available actions
Data From
Monitoring
Tools
System details
 Preference tuning value (PTV)
PTV =
Ns
Iw
x const x
D
D
 Preference value (PV)
PV = oldPV + PTV
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)
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
Implementation
Server component
Calculating preferences for actions
Invoke actions
Stores actual view of network and actual
knowledge base
Validation of rules
Presentation component
Extension of Local-Monitor
Simple simulator of network
Local-Monitor component
 Acquiring data from external monitoring
systems (Zabbix)
 Sending data to Saude-Net server
GUI component
Create rules
Simple validation
Data representation
Form generation
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
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
More details
 Poster number: 6
Thank you for your attention!