The operator UI is a proposed extension to the existing Web Management Console.  It targets those in the Operator role.  These people are typically concerned with monitoring a Qpid instance, rather than configuring.  This features aims to put all the information that the Operator needs in order to help to understand the health of the application.

Requirements

NumPriorityRequirement
QUERY1H

Ability to query Queues and Connections in a flexible manner. The operator will want to answer questions such as:

  • show the names of queues where all the queue depth exceeds x
  • show the depth of all queues where the oldest message age exceeds date/time

The operator must be able specify a results set that includes an arbitrary set of attributes.
The operator must be able limit the results set in an arbitrary way by specifying an expression in terms of the attributes and boolean logic.
Queues and Connections must be supported. Other object type may be supported too.

QUERY2HThe results set must be sortable by one or more attributes in the result set.
QUERY3HThe results set must be paginated limiting the result set sent over the wire.
QUERY4HThe system must allow the user to form the query in an intuitive way and assist the user to correct mistakes. The system must not assume that the operator has expert knowledge of the Broker's internal.
QUERY5HThe operator must be able to edit an existing query.
QUERY5HThe Operator must be able to elect to save queries so that they persist for the next session
QUERY6HThe system must support ad-hoc queries. These queries are not saved.
QUERY7H

The Operator must be able to flag a query as automatically refreshing.

A query flagged in this way will automatically rerun and the results will appear automatically. Any existing sorting and pagination must continue to apply.

The operator should be able to specify the frequency with which a query refreshes.

QUERY8MThe Operator should have the ability to export the result of a query to a file.
QUERY9MThe Operator should be able to click through from a query results to its corresponding object's management tab.
CHART1M

The Operator should have the ability to chart one or more statistics of an object over time.

EVENT1L

The Operate should be able to define an event. Once define, the system will generate an instance of event is triggered whenever a certain condition becomes true.

  • A queue above a certain threshold
  • Disk usage above a certain percent
  • No consumers attached to a queue
EVENT2L

Event definitions may belong to a user or may be shared amongst a group.

EVENT3LThe Operator should have the ability to view events on the screen.
EVENT4LThe Operator should have the ability to acknowledge an event
DASH1H

The UI must have the ability to define a single screen containing multiple components (i.e. queries/charts/later: events) one to allow a 'dashboard' to be formed

DASH2HThe Operator must have the ability to reposition the queries/charts on the dashboard.
DASH3MComponents with the dashboard may be resizable/minimisable.
DASH4HDashboard must persist for the next session.

 

Out of scope:

1) Queries against messages themselves.

2) Dashboard summarising multiple brokers.

 

 

  • No labels