JAppMonitor
>> Solutions
>> Register
>> Log In
>> JBuildingBlocks
>> MonitorIt
Please consult our detail description section for more details. In the grand scheme of things, our goal is to bridge the gap between traditional Software Developers/Architects and Network Operations Centers/CIO/CTO/Operators that supervise and monitor software applications/solutions in production environment. In the same way that JUnit or TestNG have revolutionized the way software applications are designed and developed, our goal is to modify the way software applications are designed and developed so that the final and critical production phase is an integral part of the overall design and development process.
You can use the built-in reporting features and can also directly access the collected data in the database to write your own ad hoc report with your own third party tool (e.g. crystal reports...).
- 1 repetitive lifecycle for monitoring purposes (e.g. pb detection, result storage, pb filtering....pb notificaton)
- 1 API for on demand admin/management purposes (e.g. get results from X1 t oX2, disable..., on demand report... )
a monitorlet goes through a succession of individual phases ...
each phase is represented by an interface
there are n interfaces with a default implementation (a handler) for each
built for customization (typically for pb detection)
- the raw or individual result: the result of each monitorlet execution is stored in the database and is available for data retrieval
- the aggregated results : what is an aggreated result: based on an industry standard (see RFC ... ), instead of storing each individual results, the results average, min,max and std are stored for each 15 min interval (96 buckets per day...) why the aggregated:
1) primary reason is data storage:
1 monitorlet that is executed evey 5 seconds -> 720 results per hour, 17280 per day, 535680 results per monh, 6307200 per year... prohibitive in most cases ...
2) consolidated results are more meaningful as they are less subject to variations: average allows us to filter the out of the ordinary situations / spikes... why does the framework provide both?
best of both words: you get the entire details for the past 24 hours as well as the overall history while minimizing your data storage requiremnts and havin more meaningful results
raw results:
4 columns: idTask datetime type result
Need the type for 2 reasons:
1) to be able to change the display (e.g. cross intead of bullets) of he results when a warning/error occured
2) the recurrent task that builds the aggregated type is so simple to implement :)
Note: when error/warning occurs, a raw result is stored as well (with 0 if no value is available) aggregated results:
9 columns: idTask datetime avg max min std #ok #war #errors
N columns: idTask | datetimeFirstDetection | datetimeLastDetection | nb of detection / occurences (in a row) | pb description (summary, less than x characters for comparison) | pb full details In separate tables (in case not used): | pb acknowledged | datetime ack | ack description | pb solved | solution description advanced problem analysis (regular expressions, full text search with lucene...)
Table of Contents
What is JAppMonitor?
JAppMonitor is a free Java™ software application that:
- Continuously monitors your applications to make sure that they are up and running
- Notifies you in real time of any problem
- Maintains valuable historical performance data for report generation, performance analysis and problem investigation
Please consult our detail description section for more details. In the grand scheme of things, our goal is to bridge the gap between traditional Software Developers/Architects and Network Operations Centers/CIO/CTO/Operators that supervise and monitor software applications/solutions in production environment. In the same way that JUnit or TestNG have revolutionized the way software applications are designed and developed, our goal is to modify the way software applications are designed and developed so that the final and critical production phase is an integral part of the overall design and development process.
Detailed Description
MonitorIt is a client/server software application that continuously monitors the availability of your applications by simulating the behavior of your customers. For instance, to monitor a web based
application, MonitorIt generates the same request that
your customers would generate with their browser. Similarly, to monitor
an e-mail server, MonitorIt would regularly send and retrieve
an e-mail message...
MonitorIt provides you with the peace of mind that you know that your applications
are up and running and that you will be immediately notified of any problem.
MonitorIt also collects historical performance data and generates report for performance analysis, trend analysis and problem investigation.
You can use the built-in reporting features and can also directly access the collected data in the database to write your own ad hoc report with your own third party tool (e.g. crystal reports...).
Monitorlet: interfaces and handlers
A monitorlet handles two types of behavior: :
- 1 repetitive lifecycle for monitoring purposes (e.g. pb detection, result storage, pb filtering....pb notificaton)
- 1 API for on demand admin/management purposes (e.g. get results from X1 t oX2, disable..., on demand report... )
a monitorlet goes through a succession of individual phases ...
each phase is represented by an interface
there are n interfaces with a default implementation (a handler) for each
built for customization (typically for pb detection)
Results
JAppMonitor handles ad maintains two types of result for any given monitorlet:
- the raw or individual result: the result of each monitorlet execution is stored in the database and is available for data retrieval
- the aggregated results : what is an aggreated result: based on an industry standard (see RFC ... ), instead of storing each individual results, the results average, min,max and std are stored for each 15 min interval (96 buckets per day...) why the aggregated:
1) primary reason is data storage:
1 monitorlet that is executed evey 5 seconds -> 720 results per hour, 17280 per day, 535680 results per monh, 6307200 per year... prohibitive in most cases ...
2) consolidated results are more meaningful as they are less subject to variations: average allows us to filter the out of the ordinary situations / spikes... why does the framework provide both?
best of both words: you get the entire details for the past 24 hours as well as the overall history while minimizing your data storage requiremnts and havin more meaningful results
Database layout for results
raw results:
4 columns: idTask datetime type result
Need the type for 2 reasons:
1) to be able to change the display (e.g. cross intead of bullets) of he results when a warning/error occured
2) the recurrent task that builds the aggregated type is so simple to implement :)
Note: when error/warning occurs, a raw result is stored as well (with 0 if no value is available) aggregated results:
9 columns: idTask datetime avg max min std #ok #war #errors
Database layout for problems
On a per problem:
N columns: idTask | datetimeFirstDetection | datetimeLastDetection | nb of detection / occurences (in a row) | pb description (summary, less than x characters for comparison) | pb full details In separate tables (in case not used): | pb acknowledged | datetime ack | ack description | pb solved | solution description advanced problem analysis (regular expressions, full text search with lucene...)
References
Please consult the following pages for more details: