Reflex – New Face | Same Reliability!

Insider Technologies is pleased to share the redesigned Graphical User Interface for Reflex monitoring in advance of Insider Technologies attendance at TBC2019.

The Reflex Graphical Console is known as Status Monitor. This view represents the overall status of a single NonStop node.

Status Monitor helps an installation to manage their NonStop nodes and active services by providing a graphical view of nominated exception conditions. Installations that need to manage their network other than “by exception” can witness a richer EMS event stream by using the Status Monitor top-level views in conjunction with the text based Console facility.

The Status Monitor display is made up of columns known as classes, and within classes, icons that can represent a group of objects or a single object. Classes can be built to represent subsystems, services or local User applications.

The structure of this display is completely at the discretion of the User. The most common approach is to create either status or service views.

Status views are Operations driven where groups of “like” things, such as disc drives or spoolers, are assembled into the same class. A service class however, could contain a set of process icons, a set of file icons, a spooler device and a specific communications line, all of which support a particular application. Either approach is acceptable and it is possible to implement both and have the same icon in more than one class. Icons can represent physical objects such as a communications line or a state such as “TMF Disabled”.

Icons in the Status Monitor display can flash either blue (vulnerable) or red (down). Vulnerable is meant to illustrate that a service is continuing but that it is threatened. Losing a disk path is an example of Vulnerability.

Network Monitoring

Reflex needs to be installed on each of the NonStop nodes that will be monitored. Each Reflex system will connect to its own local Primary EMS collector ($0) and selected alternate collectors, and listen and process local events based on the local event database.

Automation and escalation to external agencies such as an Enterprise Manager will be the responsibility of each of the local Reflex systems.

Each local Reflex node will be responsible for maintaining a table of the status of the icons on display for its node. This will be updated as the Event Monitor passes new information to it as it arrives in the local EMS logs.

Outside of this, the Reflex  administrator needs to create a Network Hierarchy file that contains the names of all of the Reflex  nodes in the network. At least one of these nodes needs to be classed as the parent and typically it is the node that you have your Reflex  client connected to.

Each child node will then send regular status updates to the parent(s) stating that during the last poll period they have processed;

• no events or
• at least one vulnerable event or
• at least one down event.
• A fourth condition also exists, the parent expects a message from a child and it never arrives.

The parent node has a state table for the nodes in the network and it is used to animate a display showing node icons. The icons will be shown as grey (no messages processed), red (at least one down), blue (at least one vulnerable) or orange (no child message received).

In addition to this reactive monitoring of subsystems events, performance metrics, Reflex provides proactive monitoring to check the health and status of subsystems such as processes, files, tapes, queues, TMF, batch.

This is but the tip of the iceberg when it comes to Reflex’s monitoring capabilities. Be sure to seek out Karl Gilbank at TBC 2019 for more information.

https://www.insidertech.co.uk/solutions

hello@insidertech.co.uk

+44 (0) 161 876 6606