BMC AMI Ops user interface scenarios

The following scenarios describe how you can quickly identify issues, and locate their source, with BMC AMI Ops User Interface (BMC AMI Ops User Interface).

Scenario: Exploring the source of increased CPU consumption

This scenario describes how an organization uses BMC AMI Ops User Interface to quickly identify the source of an increase in CPU consumption.

The following users are involved in the workflow:

Gwen, the operator, notices a problem

As a system operator, Gwen is responsible for monitoring the mainframe environment for unusual behavior. She uses various user interfaces, such as BMC AMI Ops User Interface.

Gwen routinely logs in to BMC AMI Ops User Interface and sees the Overview dashboard , which is sorted by severity. Following some software updates, an unexpected widget appears red, meaning at least one of the targets has a critical alarm. Gwen filters the dashboard by LPARs to get a better idea of the scope of the issue.

_{Click to enlarge the image.}

On the dashboard widget, Gwen clicks the number next to the Critical indicator to see information about the alarm.

_{Click to enlarge the image.}

Gwen clicks the alarm name, LCECABH, to see all the details. She takes a screenshot and sends it to Amit, the system programmer.

Amit, the system programmer, digs deeper

As a system programmer, Amit is responsible for installing and upgrading products that run on the the system.

Amit logs in to BMC AMI Ops User Interface and follows in Gwen's footsteps. In the alarm details, he examines the duration of the alarm and the gradual rise in severity. He compares the time to the rollout of the software updates. Amit sees more details about the relevant metric by clicking the alarm hyperlink, which takes him to the relevant view.

_{Click to enlarge the image.}

Amit uses the hyperlinks provided in BMC AMI Ops User Interface to navigate across views.

_{Click to enlarge the image.}

As he examines the view that shows CPU consumption across different jobs and service classes, Amit locates the job that exceeded the set threshold and triggered the alarm. He looks at historical data in the view for the last two hours to see when the CPU consumption started to increase. He identifies the job that caused the spike in CPU consumption (DJQ1DBM1) and notices a trend. Using the graph, Amit finds the time interval within which CPU consumption started to rise.

_{Click to enlarge the image.}

Amit focuses on the job which relates to the recent database updates. He examines the previous and next hour intervals to get a better understanding of when the CPU consumption increased for this job.

_{Click to enlarge the image.}

The interval data informs Amit that the CPU consumption for job DJQ1DBM1 started to spike at 04:30 AM, which coincides with the time that the upgrades were applied for the databases.

Amit contacts his supervisor and provides details. They check for system upgrades in that time frame. Amit finds that an unusual deadlock, due to a database upgrade, caused this issue and instructs the relevant team to roll back the changes and investigate further.

Amit uses the breadcrumbs at the top of the screen to return to the dashboard, where he can switch services. A BMC AMI Ops service (also known as the BMC AMI Ops Host Server) is part of the BMC AMI Ops Infrastructure used to access BMC AMI Ops monitored environments.

Amit examines the behavior on other services to see if the issue is isolated to one service or is more widespread.

Scenario: Monitoring database performance

This scenario describes how an organization uses BMC AMI Ops User Interface to monitor key performance indicators for a database.

The following users are involved in the workflow:

Gwen, the operator, notices a problem

As a system operator, Gwen is responsible for monitoring the mainframe environment for unusual behavior. She uses various user interfaces, such as BMC AMI Ops User Interface.

Gwen routinely logs in to BMC AMI Ops User Interface and sees the Overview dashboard , which is sorted by severity. Today she notices that the DB2 widget is red and that one of the targets has a critical alarm.

On the dashboard widget, Gwen clicks the number next to the Critical indicator to see information about the alarm. On the Alarms page, she sees the text of the alarm and how long it has had a Critical status.

In the following image:

• Text column shows ActThrd > 5
• Severity Duration column shows 03:05:39

_{Click to enlarge the image.}

Gwen clicks the alarm name, STDB2VSAL, and examines the alarm details.

_{Click to enlarge the image.}

Gwen takes a screenshot and sends it to Amit, the system programmer.

Amit, the system programmer, digs deeper

As a system programmer, Amit is responsible for installing and upgrading products that run on the system.

Amit logs in to BMC AMI Ops User Interface and follows in Gwen's footsteps. From the Alarm Details page, he clicks the hyperlink to see more details about the issue in the view.

A standard Db2 view, STDB2VS, opens and Amit notices that the Act Thrd column displays the number of active threads as 8. A red threshold indicator shows that the threshold is set to 5.

_{Click to enlarge the image.}

Amit clicks the number in the Act Thrd column. A new view opens displaying the list of active threads. In the User Status column, he sees different user and monitor threads.

_{Click to enlarge the image.}

Amit takes this information to the relevant team to see why there are so many threads running simultaneously. The team can stop unwanted threads.

Where to go from here

For information about the BMC AMI Ops User Interface server installation, see Installation System and Customizing-the-BMC-AMI-Ops-user-interface.

If BMC AMI Ops User Interface is already installed, learn how to access and use features of the product in the following topics: