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"
(Added use case actors.) |
|||
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[COSMOS|COSMOS Main Page]] > [[COSMOS Use Cases|COSMOS Use Cases]] | |
| − | + | 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. | |
| − | + | ||
| − | Monitoring | + | ==Monitoring UI Workgroup: Meeting Minutes== |
| + | [[Monitoring UI Workgroup-24-Oct-2006|24-Oct-2006]] | ||
| − | + | ==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. | |
| − | * The | + | * The User Interface needs to be "model aware", understand the thing it's monitoring (SML) |
| − | * The | + | * 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: ??== | ||
Latest revision as of 14:06, 14 December 2006
COSMOS Main Page > COSMOS Use Cases
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.
Contents
Monitoring UI Workgroup: Meeting Minutes
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.
- The User Interface needs to be "model aware", understand the thing it's monitoring (SML)
- 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