|System z on Facebook
Top 10 Most Frequently Asked Questions About IBM zAware
Caroline Exum 270004MPQK email@example.com | | Tags:  bao im systemz security zec12 zenterprise sm aspen_payton systems appdev zaware development | 4,043 Visits
In the months leading up to the release of IBM zAware, we spoke to many customers and testers about our progress. Our goal was to collect opinions and solicit additional input. During these discussions, a number of questions surfaced time and again. I would like to address some of these commonly asked questions for you here. Without further ado, I present "The Top 10 Most Frequently Asked Questions about IBM zAware"
(10) Where does IBM zAware run on my system?
IBM zAware runs on your system as a special purpose firmware partition. You will not need to acquire any special skills to manage this additional partition. One major benefit of running IBM zAware in a special purpose partition is that we do not use MIPs on z/OS for executing calculation intensive analytics. This means the processing performed by IBM zAware cannot adversely affect the health of the monitored client systems. Another major plus is that IBM zAware will not be affected by a "sick" partition. If a problem occurs in z/OS which results in a negative impact to the health of the system, IBM zAware will continue to function normally. In fact, since IBM zAware looks at message traffic in near real-time, you may be able to look at the "sick" partition in the IBM zAware GUI to see if an anomalous message pattern was detected that could help you diagnose the source of the problem.
(9) Do I need a separate IBM zAware partition for each sysplex?
No, a single IBM zAware partition can be used to monitor multiple systems, sysplexes, and CECs. It's up to you to determine how you want to configure your IBM zAware environment.
(8) What releases are supported by IBM zAware?
The system hosting the IBM zAware partition must be an IBM zEnterprise EC12 (zEC12). However, IBM zAware partition can monitor z/OS systems at many different configurations. For the full list of supported configurations, see Chapter 2 in the System z Advanced Workload Analysis Guide (IBM zAware Guide).
(7) Where does the data used and generated by IBM zAware reside?
IBM zAware stores persistent data on Extended Count Key Data (ECKD) direct-access storage devices (DASD). You specify the storage devices that will be used. The data stored includes a reduced form of OPERLOG data from each monitored client system sent to the IBM zAware server via z/OS system logger, as well as the models and analysis results generated for each monitored client.
In order to easily handle clean up of old data, you can configure retention times through IBM zAware GUI. Three different retention periods may be configured. The first retention period is "Instrumentation data retention time." This is how long we will keep the data received from the monitored clients, which we use to generate your models. The second retention period is the "Training models retention time." This is how long we store models generated for each monitored client. The last retention period is "Analysis results retention time." This is how long we keep the analysis results for each monitored system. Analysis results show the comparison of system activity against the model of expected behavior. When setting these retention periods, you should consider whether your business has any audit requirements that may define how long you must keep your data.
(6) How do I access IBM zAware?
All you need to access IBM zAware is a browser and the URL of your partition!
(5) How do I authorize users to access the IBM zAware GUI?
In order to simplify the process of allowing users to access the GUI and avoid duplication of effort, IBM zAware can authenticate user login requests against an existing LDAP server. You can set up the connection to your LDAP sever through the configuration page on the IBM zAware GUI. Alternately, you may also choose to authenticate users against a local file-based repository.
(4) Do I need to wait a minimum number of days for IBM zAware to collect data before I can create a model and start monitoring my client systems?
No, you do not need to wait for new log data to be collected before you can start using IBM zAware. Previously collected formatted OPERLOG or SYSLOG data can be used as initial input to IBM zAware. Log data in the OPERLOG format is a requirement of IBM zAware for real-time analysis. OPERLOG provides us with a non-intrusive way to mirror logstream data. It also allows us to collect suppressed messages, so our results will not be skewed by message flood automation. If you are using SYSLOG now you can run OPERLOG as well. You do not have to abandon the SYSLOG format in order to fulfill the OPERLOG requirement.
You will transfer your previously collected OPERLOG data to the IBM zAware server using the z/OS bulk load client for IBM zAware. Once the log data has been transferred there is one additional step before you can create a model. When this previously collected data is transferred, we do not have a way to identify the sysplex where it originated. You will go to the Priming Data panel on the IBM zAware GUI to assign the bulk loaded data to the proper sysplex. When you assign data to a sysplex on this page, we stop all activity on the IBM zAware server to ensure the data is all in the same state during the assignment process. Since stopping activity on the server can be disruptive, it is a good idea to assign bulk loaded data in large batches.
(3) I experienced a day with unusual message activity. How do I prevent this data from being used to build a model of what is normal for my system?
IBM zAware uses your log data to create a model of expected behavior for each monitored client system. If your system experiences a day where log data was extremely unusual (for example, due to unexpected errors or temporary change in processing), you may want the option to exclude it from consideration when creating a model. It is very easy to exclude a day from future models. Excluded days are configured using the Manage Model Data function in the Monitored Systems table on the Training Sets page.
(2) What is the difference between IBM zAware and z/OS Predictive Failure Analysis?
As a developer, I have had the pleasure of working on both the z/OS Predictive Failure Analysis and IBM zAware products. At first glance, one may think that IBM zAware and z/OS Predictive Failure Analysis (PFA) are very similar. In fact, they may appear to be performing nearly the same function! However, these tools have more differences than you might think.
While PFA and IBM zAware both attempt to isolate soft failures, they go about this task in completely different ways. It is important to understand that PFA is attempting to predict failures, while the goal of IBM zAware is to help you quickly diagnose a problem.
Another major difference between these products is the location where they run. PFA runs within z/OS, so it uses resources allocated to the operating system and will be affected if the operating system becomes nonfunctional. As I mentioned earlier, IBM zAware runs on a special purpose partition. It is using resources which have been allocated to the partition, and thus will not be affected by problems which might occur on any of its monitored client systems. If you identify a client system with a problem, you will be able to inspect that system via the IBM zAware GUI to see, in near real time, whether any unusual log activity was reported which might give immediate clues to the root of the problem.
Customers access IBM zAware using a GUI which provides an easy, centralized way to change configuration values and view analysis results. PFA generates reports which must be viewed through the System Display and Search Facility (SDSF) and issues alerts via messages (which are issued as a WTO by default).
PFA currently looks at a few different types of data. Since PFA is integrated with IBM Health Checker for z/OS, we refer to the different metrics it examines as “checks”. In z/OS 1.13, PFA has six PFA checks: Common storage usage, LOGREC arrival rate, Message arrival rate, SMF arrival rate, JES spool usage, and Enqueue request rate. In the first release of IBM zAware, we are focusing on a single metric: Messages. The volume of messages sent to logs on z/OS typically will vastly exceed the ability for an operator or programmer to easily isolate the single message or set of messages that could allow them to identify the problem. The goal of the initial release of IBM zAware is to make this process much easier. We analyze message patterns and identify anomalies for the system operator or programmer to examine.
IBM zAware and z/OS Predictive Failure Analysis are complimentary tools which can help you enhance and extend the resiliency of your systems.
(1) What types of data will IBM zAware support in the future?
This final question brings us to the customer participation portion of this blog post! We want to advance future releases of zAware into the areas that are most valuable to our customers. We welcome your input regarding the types of data you think we should support in future releases.
Do you have any questions, comments or feedback for the zAware Development team? Comment below!
This is part three in a four part series on IBM zAware, a product that was introduced with the zEnterprise EC12. Stay tuned to the Mainframe Insights blog for more on IBM zAware!
The Journey to IBM zAware (Erin Farr)
zAware Installation and Startup (Angela Fatzinger)
Aspen Payton is a Staff Software Engineer with five years of experience on System z working with IBM zAware and z/OS Predictive Failure Analysis. Prior to this she worked for nine years on System i performance tools such as Collection Services, Job Watcher and Disk Watcher.