The Sentra E-Stream product can deploy a comprehensive EMS lean extraction client to the HP NonStop platform(s) for the relay of dynamically filtered EMS event messages to a nominated Windows server.
This relay of events can be used to monitor HP NonStop Guardian, Open System Services (OSS) and application EMS events, e.g. TMF, Safeguard, Pathway, WebSphere MQ, Aleri Atlas, COPE and STAR, XPNET and BASE24™.
For those HP NonStop subsystems that do not typically raise EMS events, e.g. file, TCP/IP, process, Spoolcom etc., Sentra E-Stream comes complete with EMS agents that can be configured to monitor these subsystems and issue alerts as required.
Relayed EMS events are stored in a Microsoft SQL or Oracle database and can be used to drive graphical, web-based hypervisors and near real-time dashboard charts, e.g. failed event totals received for XPNET stations, processes, lines, links.
Simple or compound rules can be constructed to spot vulnerable or failing subsystems on the HP NonStop platform or compromised areas of a live application, e.g. VISA interchange process down.
The software allows for 2 levels of event filtering. Two EMS collectors can be attached and a single event filter object (a second filter table also exists for tighter control of incoming events). A timestamp can be configured for re-start purposes in the event of failure. This can also be used to go back in time.
A comprehensive EMS event query screen exists in the Sentra E-Stream Web client. This can be used to query on all mandatory EMS event tokens (wildcards are also allowed) currently held in the Sentra E-Stream database. Commonly used queries can be saved for later access and results can be output to a CSV file for importing into a spreadsheet.
Microsoft SQL Reporting Services are securely integrated into the Sentra E-Stream Web client to enable timely management reports to be constructed for EMS event ranges whether by event number, SSID or any other mandatory token. These EMS reports can be manually or automatically relayed to configured email addresses.
Customer specific tailored EMS tokens can be integrated following a short software development.
Also, since BASE24 XPNET does not have an audit log, Sentra E-Stream is able to monitor the EMS logs for XPNET security violations and escalate potential security threats. Management Information reports can then be produced, e.g. end of day or cut off period.
EMS message event tokens monitored by Sentra E-Stream :
- Event Generation Time
- HP NonStop Node Number
- Event Log Time
- EMS Event Number
- CPU number
- Process Identification Number (PIN)
- Emphasis Supression Flag
- Action Needed
- Action ID
- Event Pass Value
- SubSystem Identifier (SSID)
- HP NonStop Node Name
- Event Subject
- Subject Manager
- Process Description
- User ID
- User Name
- EMS Collector
- EMS Event Text
Customer specific tailored EMS tokens can be integrated following a short software development.
To gain full access to the HP NonStop EMS monitoring screenshots, please register with this website (click the 'Register' link - at top right of page).
NOTE: Please provide a company / organisation email address during the registration process.
Once your website registration is approved (usually within 24 hours), then 'Login' to the website and navigate to this EMS monitoring web page and the example screenshots will be available for viewing at the bottom of the page.
If you are already a member of this website, 'Login' as normal.
Minimum Windows Hardware Requirements
For an Oracle database installation of Sentra E-Stream, contact ITL.
For optimum performance, it is recommended that the minimum specification of your hardware and software is as follows :
- Windows Server 2003 / 2008 / 2008 (R2) / 2012 (64-bit also) with the latest service packs
- Microsoft SQL Server 2005 / 2008 / 2012 (64-bit also) with the latest service packs
- Either; Tomcat, IBM WebSphere, JBoss (formerly BEA WebLogic) web application servers (ask ITL about MS Internet Information Services- IIS)
- Browsers; Internet Explorer (IE) ver. 7+, Google Chrome, Safari, Firefox
- Intel Mid to High-End, Multi-Core processor
- 16+ GB RAM recommended
- SCSI interface (SCSI2 Ultra-Wide recommended)
- 50 GB Single Drive for operating system and SQL Server software
- *500 GB Single Drive for the SQL server database (RAID 0+1 recommended)
- 20 GB Single Drive for the SQL server log file (RAID 0+1 recommended)
- Graphics resolution 1024 x 768 recommended
- 17" or larger colour monitor is also recommended
The above specification is for guidance only. The specification of your Windows server will be dependent on your individual needs. Please contact the Insider Technologies Helpdesk for assistance in establishing the specification of your server.
SQL Server Versions Supported by Sentra E-Stream (also install Microsoft SQL Reporting Services)
The Sentra E-Stream database is compatible with the following variants of SQL Server :
- 2005 / 2008 / 2012 Standard Edition
- 2005 / 2008 / 2012 Enterprise Edition
- 2005 / 2008 / 2012 Developer Edition*
- 2005 / 2008 / 2012 Express – the default installation on the CD uses SQL Express with Advanced services, so that SQL Reporting Services is available
* Some SQL editions include a concurrent workload governor. Performance degrades when more than five queries are executed concurrently. Sentra E-Stream will work with these versions of SQL Server but performance may be unacceptably slow and its installation is not recommended for high volume usage.
SQL Express editions support databases with a limited maximum size (4Gb for SQL Express 2005). Users who anticipate large database storage requirements should consider installing the Enterprise edition of Microsoft SQL Server, or contact Insider Technologies for advice.
Introduction
The EMS subsystem is installed on every NonStop system. It is started when your machine is loaded and although it is something that you can tune, you cannot shut it down.
It provides the native logging environment for your NonStop node. All the hardware, operating system and utility subsystems write their logging information to EMS. The log messages cover error conditions such as hardware failure but they also cover plain information such as a tape being loaded. As the log information covers more than just errors, each message is referred to as an event, hence the Event Management Service (EMS).
Although your application can still write log messages to disc files and spooler locations, it will be better integrated with the NonStop node if it too writes log messages to EMS in the required proprietary format. This task requires some programming expertise; however the Sentra E-Stream gateway product can provide this interface into EMS for your application and HP NonStop network.
Already you may sense that the logs will be filled with events that could be ignored and that basing a management regime for your NonStop node on EMS will require much research and development. Conquering this issue is the unique strength of Sentra E-Stream.
Capturing and Processing Events
EMS Event or log information is stored in a set of disc files. You are in control of where the files are held and how many you want to retain.
Any process wishing to write to these log files does not need to know where they reside as the files are fronted by a collector process. The primary collector process is known as $0, so if you write your log data to $0, then it is written to the appropriate disc file for you. To help spread the processing load you can have more than one collector, these extra processes are known as alternate collectors.
If you want to retrieve log messages so that you can process them, you use distributors. Distributors will ask a collector for events, you can go back in time for them or they can be forwarded on to you as soon as they are written to a log file.
Distributors can then be used to display retrieved log messages in a “pretty” format on your screen or they can be used to send retrieved events to EMS on other NonStop nodes. Finally, they can be used to send retrieved events to applications that will process them. This latter use of a distributor is the standard method that Event Management applications use to obtain their log information, and in this respect Sentra E-Stream is no different.
As this stream of events is being retrieved by a distributor you can apply a filter to it to remove unwanted information. Sentra E-Stream installs a filter for you (and you can also use a filter table).
Identifying Events
The older logging systems were based on writing strings of text to a disc file or printer. Whilst this format is the best possible for the human eye, it makes for a very inefficient format if this same log message is to be processed by a software module.
Writing these to an EMS collector generates non-unique events where all the event number tokens are set to '512'. These old style, legacy events can enriched / enhanced and made unique by Sentra E-Stream Gateway agents.
Event Management Service (EMS)
To overcome this, EMS event buffers contain numeric tags to help software process them. Each event buffer consists of 2 types of data; token codes and token values. Token codes are unique numbers that identify pieces of information and the token value is that information. For example the time that the event was generated might be token code number 1, so the buffer would contain:
1:(18:00, May 16th)
It is easier for a software module to retrieve information number 1, rather than scan a long piece of text trying to identify where the timestamp is. Although we have used number 1 in this example, the reality is that the value of these numbers is huge as they have to be unique.
As an application developer you can create events and providing you publish the values of your token codes other application programs can retrieve your events and unpack the elements with a series of simple requests (I’ll have information 100, 999 and 1002 please - SSGETTKN programmatic calls) rather than having to parse the content of the message.
Every event has a standard set of information or header tokens. These include the name of the node where the event was generated, the time it was generated and the process that generated it.
There are some other important tokens; the Subsystem Identity (SSID), the event number, the subject and the subject manager.
Each type of event needs a unique number, so that if you want to retrieve say all “PATHWAY Server frozen” log messages you can ask your distributor to obtain event “x” and all you will get is this message. This unique identity is provided by a combination of the Subsystem Identity (SSID) and the event number.
The Subsystem identity is made up of three parts; the Owner, the value and the version. The Owner of the event is usually based around the manufacturer of the event such as ACI, SI, TANDEM or INSIDER. The Subsystem value is allocated on a per subsystem basis, so PATHWAY is number 8, TAPE is number 4 and TMF is number 10. The version is the Operating system version and is documentary and can be ignored, so TANDEM.8.0 are PATHWAY events and TANDEM.4.0 are TAPE events. As with earlier timestamp and node information this information is held as series of token codes and values and can be easily retrieved from the event buffer.
The event number identifies the log message within the subsystem, so event 1061 within PATHWAY (TANDEM.8.0) is a Server being frozen but event 1049 is a User PATHWAY terminal being suspended. Using these standards, unique identities can be built up for every event that will be created on your NonStop node.
The subject value will represent the object that the event was for. In our example it will be the Server Class that was frozen. The manager is the process that controls our subject, in our example this is the PATHWAY monitor process. This is useful in the automation world as when we receive this event we can connect to the “manager” and ask it to restart the “subject”. Again subjects and managers are held as a series of token codes and values.
Finally to illustrate the event buffer principle still further we include a screen shot. The values down the left hand side of the screen are the token codes, the numbers have been converted to text values so that it becomes easier to interpret. The right hand values are the token values.
