Skip to end of metadata
Go to start of metadata

Overview of "Monitor ION Resources" Use Case

View status of any Integrated Observatory resource.


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator
References Science Concept of Operations
Uses UC.R2.52 Manage ION Processes-Deprecated
Is Used By UC.R2.11 Define Marine Observatory Resources and Policy
UC.R2.46 Operate Integrated Observatory Network
Extends  
Is Extended By UC.R2.14 Monitor an Instrument
In Acceptance Scenarios AS.R2.01A Operate Marine Observatory, AS.R2.01C Operate Integrated Observatory Network, AS.R2.04B Curate Data Products, AS.R2.04C Instrument Experts Drive Core Instrument Operations
Technical Notes  
Lead Team COI
Primary Service Federated Facility Services (Virtual Organization) Part 1
Version 1.9
UC Priority 4
UC Status Mapped + Ready
UX Exposure ONC

Summary

This information summarizes the Use Case functionality.

Through graphical user interfaces and automated monitoring tools, identify issues with the Integrated Observatory system. Detect resource limitations (e.g., space available in storage resources) before they are actually reached, in time to fix them. Provide multiple levels of notification; allow notifications to be acknowledged and reflect this in the appearance of the notifications; allow notifications to be disabled; re-issue notification in fully displayed mode if it goes away after acknowledgment but then comes back.

Assumptions

  • The same features will also be available to Observatory Operators for monitoring their observatory's resources.

Initial State

Integrated Observatory Operator is logged in.

Scenario for "Monitor ION Resources" Use Case

  1. The Integrated Observatory Operator calls up Resource Collection views to review resources on the system.
    1. Resource overviews should include summary of status and relevant metadata.
    2. Additional detail: The displays should be able to discriminate/filter based on resource type, owner class (system, user), specific owner, or a search criteria.
  2. The Integrated Observatory Operator calls up detailed Resource Page views to examine detailed information for a resource.
    1. The ability to drill down from all resources, to a particular type of resource, through subtype to identify particular resources of interest is important.
    2. The ability to filter on different types of resources is important.
  3. Upon identifying a resource with a problem, the Integrated Observatory Operator identifies the corresponding services and agents and takes remedial action.
    1. For a problem service, could pause it, put it into debug mode, move it to an isolated machine, or kill it; see [UC.R2.52 Manage ION Processes].
    2. Could also reallocate available supplies (e.g., increase disk space).
  4. <3> The Integrated Observatory system issues a notification visible to the Integrated Observatory Operator when a preset capacity threshold is reached.
    1. The word 'capacity' in this step refers to information types like disk space, CPU time, available power, communication bandwidth, and so on.
    2. Increasing notification levels are used as the situation becomes more critical.
    3. This is likely to be an event, which can trigger a corresponding visible notification.
    4. Notification can be of the severity info, warning, or alarm, the last being the most series.
  5. <3> The Integrated Observatory Operator acknowledges the alarm.
    1. The alarm is displayed but in a reduced level of visibility.
  6. <3> The condition causing an acknowledged alarm goes away, then returns; the alarm is redisplayed.
  7. <3> No Observatory Operator acknowledges the alarm for a defined period; the notification is escalated to contacting the relevant Operators via their cell phones (IMS), until someone acknowledges the alarm.
  8. <3> The Integrated Observatory Operator disables an notification for the given resource, causing an announcement to all Integrated Observatory Operators.
    1. That notification will not be displayed for that resource (though more severe alarms will still be displayed) anywhere on the system.
    2. The event is still issued but does not trigger the notification.
    3. This feature must be used carefully to ensure alarms are not inappropriately disabled.

Final State

Operations continue with the resource conditions understood and manageable.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

See the components in R2 COI Construction Plan 1.2.3.12.2.22 and R2 COI Construction Plan 1.2.3.12.2.22 for complementary information on this Use Case.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.