Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Monitoring User Interface use cases"

(General Requirements)
Line 7: Line 7:
  
 
* What reports to provide?   
 
* What reports to provide?   
* What templates should we provided
+
* What templates should we provided?
 +
* What report libraries should be provided?
 
* “Auto update” on reports, e.g. refresh the view every “n” seconds/minutes?
 
* “Auto update” on reports, e.g. refresh the view every “n” seconds/minutes?
 
* Support the idea of “drill down” reporting or only top level?
 
* Support the idea of “drill down” reporting or only top level?
Line 15: Line 16:
 
* What about login/security?  JDBC connection only?
 
* What about login/security?  JDBC connection only?
 
* Ad hoc reporting
 
* Ad hoc reporting
 
+
* How do we expect these reports to be consumed by other management applications, e.g. re-use in commercial applications?
  
 
==Use Case 1: Check the health of a resource==
 
==Use Case 1: Check the health of a resource==

Revision as of 10:47, 24 October 2006

Started some general brainstorming about the Monitor UI component of COSMOS. Started off with a general set of questions to help flush out the requirements.


General Requirements

  • The Monitor UI is primarily a reporting user interface on top of the aggregated and normalized collected data for the purpose of health monitoring.
  • What reports to provide?
  • What templates should we provided?
  • What report libraries should be provided?
  • “Auto update” on reports, e.g. refresh the view every “n” seconds/minutes?
  • Support the idea of “drill down” reporting or only top level?
  • What about linking/referencing external information from reports, e.g. to a run book? Could be an extension point of some sort?
  • Simplified view for levels of sensitivity, e.g. a “sensitivity” filter. Response time may be an example where this would be appropriate.
  • JDBC and/or XML data sources?
  • What about login/security? JDBC connection only?
  • Ad hoc reporting
  • How do we expect these reports to be consumed by other management applications, e.g. re-use in commercial applications?

Use Case 1: Check the health of a resource

Actor:

System Admin


Description:

In this use case, the user would run a canned report that looks at the health of a particular resource. The report should have some saved parameters that can applied, e.g. show me all the servers where CPU utilization if above 80%. The 80% should be customizable.


Desired Outcome

The System Admin can quickly determine and evaluate the health of the system by studying a generated report. This information will help resolve issues such as service disruption and performance, and help determine what priority to place on the problem.


Assumptions

  • The report the System Admin is executing has been pre-built.
  • The report is deployed as a web application and can be accessed through a well known URL


Process Flow

  • The System Admin opens the url associated with a pre-defined report
  • When prompted, the System Admin enters the report parameters



Use Case 2: Test/Debug resource instrumentation

Actor:

Developer


Description:

TBD


Use Case 3: ??

Back to the top