View Source

h2. Overview of "{metadata:Use Case Name}Monitor ION Resources{metadata}" Use Case

*{metadata:Description}View status of any Integrated Observatory resource.{metadata}*
{metadata-from:Release 2 Use Cases|UCTipBlock}
*Related Jira Issues:*   [Open|{metadata-from:Use Case Number}%22+OR+description+~+%22UC.R2.{metadata-from:Use Case Number}%22+OR+comment+~+%22UC.R2.{metadata-from:Use Case Number}%22)+ORDER+BY+priority+DESC,+status+DESC]   •   [All|{metadata-from:Use Case Number}%22+OR+description+~+%22UC.R2.{metadata-from:Use Case Number}%22+OR+comment+~+%22UC.R2.{metadata-from:Use Case Number}%22)+ORDER+BY+resolution+DESC,+priority+DESC,+status+DESC]

|| Use Case Release | R2 |
|| Use Case Number | 40 |
|| Original WBS Use Case Name | Monitor ION resources |
|| R1 Use Case Number | |

h3. 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 |

h3. Summary

_This information summarizes the Use Case functionality._

{metadata:Detailed Summary}
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.

h3. Assumptions

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

h3. Initial State

{metadata:Initial State}
Integrated Observatory Operator is logged in.

h2. Scenario for "{metadata-from:Use Case Name}" Use Case

# *The Integrated Observatory Operator calls up Resource Collection views to review resources on the system.*
## Resource overviews should include summary of status and relevant metadata.
## Additional detail: The displays should be able to discriminate/filter based on resource type, owner class (system, user), specific owner, or a search criteria.
# *The Integrated Observatory Operator calls up detailed Resource Page views to examine detailed information for a resource.*
## The ability to drill down from all resources, to a particular type of resource, through subtype to identify particular resources of interest is important.
## The ability to filter on different types of resources is important.
# *Upon identifying a resource with a problem, the Integrated Observatory Operator identifies the corresponding services and agents and takes remedial action.*
## 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].
## Could also reallocate available supplies (e.g., increase disk space).
# <3> *The Integrated Observatory system issues a notification visible to the Integrated Observatory Operator when a preset capacity threshold is reached.*
## The word 'capacity' in this step refers to information types like disk space, CPU time, available power, communication bandwidth, and so on.
## Increasing notification levels are used as the situation becomes more critical.
## This is likely to be an event, which can trigger a corresponding visible notification.
## Notification can be of the severity info, warning, or alarm, the last being the most series.
# <3> *The Integrated Observatory Operator acknowledges the alarm.*
## The alarm is displayed but in a reduced level of visibility.
# <3> *The condition causing an acknowledged alarm goes away, then returns; the alarm is redisplayed.*
# <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.*
# <3> *The Integrated Observatory Operator disables an notification for the given resource, causing an announcement to all Integrated Observatory Operators.*
## That notification will not be displayed for that resource (though more severe alarms will still be displayed) anywhere on the system.
## The event is still issued but does not trigger the notification.
## This feature must be used carefully to ensure alarms are not inappropriately disabled.

h3. Final State

{metadata:Final State}
Operations continue with the resource conditions understood and manageable.

h2. Comments

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

{metadata:Use Case Comments}
See the components in [R2 COI Construction Plan|] and [R2 COI Construction Plan|] for complementary information on this Use Case.

{metadata-from:Release 2 Use Cases|UCNavBlock}