Click to open image in a new window (288kb JPG)
The screen capture is of a Tivoli Event Viewer displayed from within the TEC Console. The top and bottom panes represent events that the Operator has copied into his/her Working Queue (top) from the All Events queue (bottom). In this case, the Operator has claimed all of the events. SAS uses a combination of customized IBM Tivoli non-TME Logfile Adapters, Tivoli Monitoring, and UNIX shell scripts to monitor and control the SAS BI server environment.
The first few events are an example of SAS handling rotation of logfile names, something that the Tivoli Logfile Adapter normally won't do. Around midnight each day, the SAS Metadata and OLAP servers close their respective logfiles and open new ones with an encoded form of the new day's date embedded in the logfile's name. The Tivoli Logfile Adapter expects a monitored log to remain at a static filename. When SAS BI servers rotate their logs, they write a specific log entry which is used to generate a new event: SAS_Logfile_Continues.
When the Tivoli Event Server receives a SAS_Logfile_Continues event, a SAS event rule causes the Event Server to invoke
a UNIX shell script which re-links a static logfile name to the day's current log instance. The small blue curlicue
to the left of these events indicates that the event caused this automated task to run.
The SAS configuration of the Logfile Adapter monitors SAS server logs for additional events such as connection attempts, login authorization failures, and state changes in the SAS servers. At Item 3, a failed attempt to access the SAS Metadata Server has been flagged as a Warning event for the Operator. The Message field shows that someone attempted to log in as "notauser".
SAS uses the Generic Script Resource Model for Tivoli Monitoring to track the status of the SAS BI servers. As a test, the developer issued a "kill -9" to force-quit the SAS OLAP server. Using SAS-developed scripts, Tivoli Monitoring noted that the OLAP server was no longer available and issued this Critical event. For this sample configuration, the server(s) are polled at one-minute intervals. In this particular case, the server was down for more than one poll interval. SAS uses a custom event correlation rule to collapse each of these Critical events into one instance. A "duplicate event" count is maintained in the Details description of the event.
The next Warning event (yellow) shows that the Operator initiated a manual restart of the SAS OLAP Server.
The restart of the SAS OLAP Server generates several New Client Connection events as the server reestablishes contact with the SAS Metadata Server.
In addition to the monitoring scripts, log format files, BAROC event definitions, and event rules, SAS supplies a Task Library with pre-defined tasks which allow Operators to start, stop, restart, and check the status and logs of SAS BI servers from within the Tivoli environment.
Note: the information on this page is subject to change.