Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Monitoring User Interface use cases"
(→Actors moved to its own page.) |
|||
| Line 1: | Line 1: | ||
| − | + | 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 | ||
| + | * “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 | ||
| + | |||
| + | |||
| + | |||
| + | UC1: The System Admin checks the health of a resource | ||
| + | |||
| + | Scenario 1: Running a pre-defined report | ||
| + | |||
| + | Overview: | ||
| + | In this use case, the System Admin 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. | ||
| + | |||
| + | |||
| + | |||
| + | UC2: Developer debugs the instrumentation of a resource | ||
| + | TBD | ||
Revision as of 23:03, 23 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
- “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
UC1: The System Admin checks the health of a resource
Scenario 1: Running a pre-defined report
Overview: In this use case, the System Admin 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.
UC2: Developer debugs the instrumentation of a resource TBD