CA Unified Infrastructure Management 8.4: System Administration Foundations 200

CA Unified Infrastructure
Management 8.4:
System Administration Foundations
200
Student Guide
20NMS20200
20NMS20200SG1 © 2014 CA. ALL RIGHTS RESERVED.

- PROPRIETARY AND CONFIDENTIAL INFORMATION -
These educational materials (hereinafter referred to as the “Materials”) are for the end user’s educational
purposes only and are subject to change or withdrawal by CA, Inc. (“CA”) at any time.
These Materials may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in
part, without the prior written consent of CA. These Materials are confidential and proprietary information of CA
and protected by the copyright laws of the United States and international treaties.
EXCEPT AS OTHERWISE STATED IN THE APPLICABLE AGREEMENT, TO THE EXTENT PERMITTED BY APPLICABLE
LAW, CA PROVIDES THESE MATERIALS “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT
LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR
DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THESE MATERIALS, INCLUDING WITHOUT LIMITATION, LOST
PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS
OR DAMAGE.
The use of any software or product referenced in the Materials is governed by the end user’s applicable license
agreement.
The manufacturer of these Materials is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to
the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-
7014(b)(3), as applicable, or their successors.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Copyright © 2016 CA. All rights reserved. CA confidential and proprietary information for CA or CA Partner
Internal Use Only. No unauthorized copying or distribution permitted.
CA Unified Infrastructure Management v8.4
System Administration Foundations 200
Table of Contents
I. Introduction
Welcome .............................................................................................................................I - 3
Learning Path ......................................................................................................................I - 4
Join MyCA and Take Advantage of CA Communities ..........................................................I - 5
Subscribe to the CA Tech Insider ........................................................................................I - 6
Social Media with CA Technologies Education ...................................................................I - 7
Technical Publications at CA Technologies .........................................................................I - 8
About This Course ...............................................................................................................I - 9
Course Agenda ....................................................................................................................I - 10
Course Objectives ...............................................................................................................I - 12
1. CA UIM Architecture and Monitoring Governance

Module Objectives ..............................................................................................................1 - 2
Identify the Key Components of CA UIM ............................................................................1 - 3
Apply Monitoring Governance to Fulfill Your Monitoring Requirements ..........................1 -24
Module Summary................................................................................................................1 -32
2. Create USM Groups

Create USM Groups ............................................................................................................2 - 4
Complete Basic Probe Deployment and Configuration Tasks ............................................2 - 6
Identify Types of Data to Monitor ......................................................................................2 - 13
Module Summary................................................................................................................2 - 16
3. Discovery & Robot Deployment

Perform a Network Discovery .............................................................................................3 - 3
Deploy Robots .....................................................................................................................3 -12
Module Summary................................................................................................................3 -15
4. Examine Monitored Data

View Monitored Data..........................................................................................................4 - 3
Examine Monitored Data in a PRD Chart ............................................................................4 - 11
Module Summary................................................................................................................4 - 14
TOC-1
© 2016 CA. All rights reserved.

5. Basic Alarm Notifications

Configure the emailgtw Probe ............................................................................................5 - 5
Activate AO Logging ............................................................................................................5 - 11
Validate Auto-acknowledgment .........................................................................................5 - 14
Build an AO Profile to Send Emails on Alarms ....................................................................5 - 16
Define Maintenance Schedules ..........................................................................................5 - 19
Module Summary................................................................................................................5 – 25
6. Advanced Monitoring Administration

Configure Monitoring with MCS .........................................................................................6 - 4
Deploy Probes .....................................................................................................................6 - 11
Configure Probes using IM and AC .....................................................................................6 - 13
Identify the Benefits of Probe Packages and SuperPackages .............................................6 - 28
Define and Configure Probe Packages and SuperPackages................................................6 - 29
Module Summary................................................................................................................6 –37
7. Perform Advanced Robot Configurations

Plan Hub-to-Hub Communications .....................................................................................7 - 3
Implement Hub-to-Hub Communications ..........................................................................7 - 5
Module Summary................................................................................................................7 - 15
8. Advanced Alarm Configuration

Build an AO Profile ..............................................................................................................8 - 4
Enhance Alarm Messages Using the alarm_enrichment Probe .........................................8 - 8
Perform Advanced Alarm Processing .................................................................................8 - 20
Incorporate Event Management Service (EMS) .................................................................8 - 24
Module Summary................................................................................................................8 - 34
9. Perform SLM Tasks

Describe Service Level Management (SLM), Service Level Agreements (SLA),
Service Level Objectives (SLO), and QoS Constraints ...................................................9 - 3
Define SLAs, SLOs, and QoS Constraints .............................................................................9 -19
Module Summary................................................................................................................9 - 29
TOC-2

10. Configure Reporting Capabilities Using PRD, List Views, and Custom Dashboards
Design Charts with the Performance Reports Designer (PRD) ...........................................10 - 3
Design Reports Using the List Designer ..............................................................................10 - 8
Design Custom Dashboards Using the Dashboard Designer ..............................................10 - 19
Module Summary................................................................................................................10 - 24
11. UMP and Portal Views

Differentiate Between Users, Accounts, and Account Contacts ........................................11 - 3
Create a Site ........................................................................................................................11 - 7
Build a Portal View ..............................................................................................................11 - 9
Module Summary................................................................................................................11 – 13
12. Advanced Probe Configuration and Troubleshooting

Perform Advanced Probe Configurations ...........................................................................12 - 3
Troubleshoot CA UIM .........................................................................................................12 - 13
Merge Data .........................................................................................................................12 - 19
Module Summary................................................................................................................12 - 18
Course Summary .................................................................................................................12 - 19
TOC-3

Introduction
CA Unified Infrastructure Management v8.4: System Administration Foundations 200
CA CONFIDENTIAL AND PROPRIETARY INFORMATION. UNAUTHORIZED COPYING OR DISTRIBUTION PROHIBITED.
Introduction I ‐ 2
Module 1: CA UIM Architecture and Monitoring Governance 1 ‐ 1
CA Unified Infrastructure Management helps your IT group reduce the time and cost
associated with monitoring, while business and IT management can gain the insights
needed to optimize resources, planning, and investments. With its broad coverage, CA
Unified Infrastructure Management eliminates the need to install, maintain, deploy,
update, and train for multiple tools.
After completing this module, you will be able to:
‐ Identify the key components of CA Unified Infrastructure Management
‐ Apply monitoring governance to fulfill your monitoring requirements
Why you need to know:
‐ By identifying the key components, you will gain a high‐level understanding of how the
logical and technical architecture is implemented.
‐ By understanding the application of monitoring governance, you can
optimally configure CA Unified Infrastructure Management to meet your specific
business monitoring requirements.
Now that you have been introduced to the monitoring governance for CA UIM you can
begin to apply it to better fulfill your monitoring requirements.
The diagram shows various inputs that influence the hierarchy of business service
management.
The CA Unified Infrastructure Management system architecture consists of the:
–Infrastructure, which is the distributed software that monitors your IT environment
and controls the data
–NIS Database (NIS), which is the database that stores the performance and trend data
relating to Quality of Service (QoS)
The infrastructure is organized in a hierarchy, which from bottom to top are:
–Probes
–Robots
–Hubs
–Domain
These architectural elements enable you to customize your monitoring setup and
organize the flow of data. They will be discussed over the next several pages.
CA Unified Infrastructure Management has two types of probes:
–Monitoring probes gather availability and performance data.
• On‐site probes gather data from the computer on which they reside.
• Remote probes monitor devices external to themselves, such as network switches
and routers.
–Service probes—also referred to as utility probes—provide product utility functions to
CA Unified Infrastructure Management.
You can easily configure probes for your own specific monitoring requirements. For
example, you can configure them to run at a specific time (timed probe) or continuously
(daemon probe). Each probe maintains its own configuration file.
CA Unified Infrastructure Management tools enable you to easily and efficiently deploy
probes to robots, the next component in the hierarchy.
Each robot has three dedicated tasks, which are performed by service probes that are
present on every robot.
–Control the probes attached to the robot, which includes starting and stopping them
at the required times.
• This is accomplished with the controller probe of the robot.
–Collect, queue, and forward the probe messages to the message bus.
• This is accomplished with the spooler probe.
–Provide a simple database service for its probes, which enables the robot to store data
for threshold monitoring and data trending, and helps ensure that collected data
survives power outages.
• This is accomplished with the hdb probe.
All robots are basically identical; it is the collections of probes they manage that
distinguish them. Probes can be grouped together into packages so that you can
appropriately deploy them to various types of servers.
If a robot contains a hub probe, it is promoted to the next level in the hierarchy, the hub.
Every deployment has one or more hubs, which perform these tasks:
–Collect all messages coming from the robots.
–Dispatch the messages to connected subscribers, message queues, or both.
–Maintain system information, such as name‐tables.
Hubs have the following designations depending on their purpose:
–The primary hub communicates with the database. Every deployment has one, and
only one, primary hub, which is created during the installation of the CA Unified
Infrastructure Management server software.
–Secondary hubs group robots according to function, geographical location,
departmental code, or other criteria. Secondary hubs are created after the server
software installation to meet the needs of your IT environment. Although secondary
hubs are optional, almost all deployments have them.
–A failover hub is a secondary hub that performs the actions of the primary hub if the
primary hub becomes unavailable.
–A tunnel hub uses VPN‐like connections to communicate through firewalls.
–A relay hub is installed in an IT Management as a Service (ITMaaS) deployment. It
communicates with the CA Unified Infrastructure Management service.
The domain is created when you install the CA Unified Infrastructure Management server
software. A site is normally set up with one domain. Various security aspects, such as
user profiles, permissions, and access rights, are distributed within the domain.
Most companies have one or more firewalls in their network, internally between
different networks and externally against the Internet or a network DMZ.
Because network administrators are often reluctant to open a firewall for the number of
IP addresses and ports that management applications require, it can be difficult to
administer and monitor the whole network from a central location.
The solution is to set up a secure shell (SSH) tunnel between two hubs that are separated
by a firewall. The tunnel sets up a VPN connection between them. All requests and
messages are routed over the tunnel and dispatched on the on‐site side. This routing is
transparent to users.
You can use the DMZ wizard to easily create tunnels between any CA Unified
Infrastructure Management hubs.
The following elements involved in data transfer are discussed over the next several
pages:
–Message bus, which includes:
• Message models
• Subscription mechanism
–Message queues
–Name service
A client can use the following methods when subscribing:
–Subscribe: The client connects to the hub and gets messages.
–Attach: If the client is not running, the hub configures a message queue to hold the
messages. When the client comes back online, all messages are passed on, including
messages received when the client was offline.
Here are some message queue scenarios:
–Permanent queue: If the hub running the Alarm Server (NAS) service goes down and
then comes back up, the NAS hub fetches all alarms generated while it was down.
–Temporary queue: When you start UMP, the UMP alarm viewer portlet subscribes to
alarm messages and a temporary queue is created. Messages are forwarded to this
queue. When the viewer is closed, the queue is removed.
The controller for each robot maintains a list of tables for all:
‐ Probes controlled by the robot
‐ Active probes, which are probes that listen to a bound port and respond to a command
set
‐ This list is distributed to the hub upon request.
‐ For example, Infrastructure Manager often requests this information.
The names found in these tables are the basis for the name‐to‐IP port resolution and
represent a CA Unified Infrastructure Management address.
‐ A client can query the controller for a name‐to‐IP resolution based on the service
name, for example, NAS.
‐ This process is similar in manner as name resolutions are queried from Domain Name
System (DNS) or Windows Internet Name Service (WINS).
This diagram illustrates how you might provide a UIM management solution to a
particular enterprise monitoring situation involving a datacenter with two remote
locations.
Having an understanding of the logical architecture, technical architecture, and message
flow, you will now identify the key components of CA Unified Infrastructure
Management.
You can do almost all the configuration, control, and management of your system
through Infrastructure Manager because it connects to an active hub and enables you to
control, configure, and manage all robots and probes connected to that hub.
Infrastructure Manager provides:
–A hierarchical view of systems being monitored
–An alarm window to view all alarms and messages
–Interfaces that enable you to configure your hubs, robots, and probes
You can do almost all the configuration, control, and management of your system
through Infrastructure Manager because it connects to an active hub and enables you to
control, configure, and manage all robots and probes connected to that hub.
Infrastructure Manager provides:
–A hierarchical view of systems being monitored
–An alarm window to view all alarms and messages
–Interfaces that enable you to configure your hubs, robots, and probes
The UMP is where you:
–Open and manage CA CSM tickets
–Monitor and manage computer systems
–Graph QoS data
–View and manage alarms
–Create SLAs and view SLA performance reports
–Create, view, and schedule reports
–Create and view custom dashboards
–Manage users
The following portlets are available:
–Account Admin enables you to manage users and user privileges, including assigning
access control lists (ACLs) to contacts within an account.
–Admin Console enables you to configure probes and manage your CA Unified
Infrastructure Management infrastructure: hubs, robots, and probes.
–Dashboard allows you to create and view dashboards.
–List Designer enables you to design lists to be displayed in List Viewer.
–List Viewer displays data in a table format in the form of text, numbers, gauges,
alarms, or graphs.
–My Tickets enables you to view basic information about your CA CSM tickets.
–Performance Reports Designer enables you to see a visual representation of QoS
data.
–Relationship Viewer provides a facility for applications to display the status of and
relationships between objects in various ways.
–Report Scheduler enables you to schedule reports to run at specified times, created in
PDF format and sent using email or FTP, or stored on a server.
–Reports contains QoS reports and SLA reports.
The following portlets are also available:
–SLA Reports provides SLA reports to show overall compliance, SLA details, Service
Level Objectives (SLOs), SLA compliance trend, and SLO data graphs.
–SLM (Service Level Management) is made up of SLAs, SLOs, and QoS data and provides
a set of tools to monitor and ensure the validity of a set of SLAs for internal and
external customers.
–Unified Reports provides advanced reporting, which enables you to run standard
reports that are provided or create your own reports in the Report Designer. This is an
optional component that you must purchase.
–Unified Service Manager (USM) enables you to set up monitoring for groups of
computer systems and to view the data collected. You can create groups of computer
systems and then assign monitoring templates to them. You can also view alarms and
perform discovery of devices on your network. USM uses the Automated Deployment
Engine (ADE) to deploy robots to Windows and Linux systems.
The newest feature in UIM 8.4 is the introduction of the Monitoring Configuration
Service (MCS). This now streamlines the manual configuration process, and makes
administrators far more efficient.
MCS allows Administrators to create a set of configuration profiles. The profiles are
applied concurrently to hundreds of target devices. MCS also automatically deploys
probes to target devices as needed.
You’ll use the provided profile types to create profiles. The profile types are designed to
focus on specific system components or functions that can be monitored. You will no
longer have to determine which probes to deploy and configure to monitor your devices.
After monitoring configuration profiles are applied to target devices, you can always
modify profiles as your monitoring needs change.
We’ll cover these features in more detail later in the course.
Unified Reporter (UR) is an optional component that provides advanced reporting for the
Unified Management Portal (UMP).
UR provides the following features:
‐ Drag and drop ad hoc report building.
‐ Drag and drop dashboard building, with live refresh, and mashups of external content.
‐ Built‐in charting that includes pie, bar, line, multi‐series, area, and many other chart
types.
‐ A library of out‐of‐box (OOB) reports that save time and effort.
‐ Database abstraction using JSON query extractors.
‐ Self‐service parameterized web reporting.
‐ Report scheduling, distribution, and historical versioning.
‐ Access to any data source, including the UIM database.
In addition, UR provides developers and power users with:
‐ The iReport graphical report designer for building more complex reports.
‐ Print‐ready pixel‐perfect production reporting
It is important to consider what you need to monitor and the associated challenges.
The general tendency is to focus on the systems/technologies that you have in place,
such as VMware and Exchange, and less on the detailed requirements.
The monitoring governance will be based on the answers to the question of what needs
to be monitored. Your goal is to document and organize the monitoring governance and
implement it in a way that supports the overall goals of the implementation. If you fail to
do this, the solution will often be implemented on an “ad‐hoc” or “on‐the‐fly” basis.
Without following a plan, it becomes difficult to maintain, understand, and build upon.
Monitoring Governance video can be found at:
http://bit.ly/1Tjlb8A
CA UIM has constructed an approach whereby monitoring aligns with and belongs in a
service catalog as part of a broader service offering.
The key idea is that the monitoring that is defined within the service offering is specific,
focused, and discreet.
The result of this improved approach is that it is documented and easier to replicate.
Furthermore, it becomes easier to remediate any issues and the approach can be put
under change control.
Focus not so much on what you are trying to monitor but what value the customer gets
from what you are monitoring.
For example, you might need to implement end‐user experience monitoring because the
application team wants to know how an application is performing for an end user. You
need to check:
–If all parts of the application are performing as well as they can or should be
–If any parts are not functioning
–Which probes and configurations you need to deploy to capture the required metrics
Put simply, monitoring governance is “what you want to monitor.”
It specifies the probes that will be used, the individual checkpoints to be enabled,
whether you will collect performance metrics for that checkpoint, what the alarm
thresholds will be, and which alarm management rules, if any, to enforce.
CA UIM has created a monitoring governance worksheet, which you will cover in more
detail as part of your services engagement.
–The service offering is what your customer buys.
–The service catalog provides more details about the offering.
From this information, monitoring governance provides the necessary detail for the
technical staff to install, configure, and maintain the system.
Finally, when you are considering monitoring governance and exploring the full
functionality of all the CA UIM probes, you will quickly discover the extent of the
capabilities. However, it is important to resist the temptation to enable everything. This is
a common mistake. People sometimes fail to take the time to understand the service
offering and service catalog and build the monitoring governance requirements from
there. Instead, they attempt to work backwards, defining the service catalog and service
offering after enabling all checkpoints. This has disastrous long‐term effects such as:
–Large databases
–Alarm flood
–A system that is exceptionally difficult to manage
Remember to take an iterative approach to monitoring, which will increase customer
value, and be sure to focus on the actionable.
For CA UIM administrators, deploying monitoring as a service in this intentional
framework reduces the overall effort required to maintain the solution. The
administrator’s manager also appreciates this because it helps contribute to lower total
cost of ownership.
On the business side, if you are a service provider, having confidence in a scalable service
catalog‐based infrastructure enables you to be quicker to get to market with those
offerings. In a service provider context, this is the concern of the program and product
managers.
Ultimately, infrastructure owners get better information about how their infrastructure is
performing and more timely notices about issues and outages.
As a CA UIM administrator you should now understand the importance of creating and
documenting a good monitoring governance plan. The goal is to start documenting at a
basic level and then continue to strive for Good, Better, Best over time.
This worksheet consists of a number of tabs that document several platforms. Within
each tab, you build out a service catalog item for each platform.
For example, the Standard Server Monitoring worksheet tab leads you to the monitoring
governance associated with that particular service catalog item.
Let’s take a closer look at that worksheet’s basic plan for monitoring standard Windows
servers. We’ll take a look at what we want to monitor and exceptions to the normal
rules, if any. These are the settings that will be also be used in the lab exercises
throughout this course.
The Standard Windows Server worksheet contains a standard for all Windows servers, of
what is being monitored, the probe used, and what metric is called. Here, for every
server in the Windows environment, we are monitoring CPU, Memory and Dis k
utilization at these thresholds.
You can set an alarm, determine the polling period, publish performance metrics, and
identify alarm thresholds. The last column is for event management rules to describe
what is to be done when you receive an alarm.
From this information, monitoring governance provides the necessary detail for the
technical staff to install, configure, and maintain the system.
Most importantly, this is documented and now becomes part of Change Management.
You should now be able to:
‐ Identify the key components of CA Unified Infrastructure Management
‐ Apply monitoring governance to fulfill your monitoring requirements
In the next module, you will:
‐ Configure basic data monitoring
Module 2: Create USM Groups 2 ‐ 1
CA UIM provides you with groups and views to enable the simple and scalable
management of the IT infrastructure of the business.
‐ Create USM Groups
‐ Complete basic probe deployment and configuration tasks
‐ You can use groups to organize your infrastructure by location, technology, or even a
service.
‐ You must deploy and configure probes to enable event and performance monitoring on
robots.
‐ Identify the types of data to monitor
‐ By identifying the types of data you can monitor, you will gain a high‐level
understanding of the data monitoring scope of the product.
You can use groups to organize your infrastructure by location, technology, or even a
service. For example, you can create a container group named eCommerce, which
contains three groups named Web Servers, Application Servers, and Database Servers.
These can be dynamic or static groups and contain servers to support each aspect of the
eCommerce service.
The membership of dynamic groups is updated automatically every 15 minutes. You can
change the update interval in the nis_server probe configuration in Infrastructure
Manager. You can create dynamic groups manually or UMP can automatically create
groups based on OS Type, OS Name, Origin, User Tag 1, or User Tag 2. With static groups,
after you specify the list of systems that are members of the group, the membership
does not change unless you manually add or remove systems.
A discovery agent must be running in your environment to discover the devices that can
be added to groups. You can use the UMP Remote Admin portlet to deploy and configure
remote discovery agents.
You can display a variety of information about a group:
–Click a group name in the tree to see a table listing information about group members.
–Click a column header in the table to sort by that column.
–Click the Alarms tab to see information about alarms for the group.
–Click the name of a system in the tree to view system properties and performance
data for the past 24 hours.
–Click an alarm icon to view alarm data for the system.
–Click the usage bar graph to view a performance report of disk usage data if the
system reports disk usage information.
The Package Archive encompasses the Local Archive and the Web Archive, from which
you deploy probes to robots.
Local Archive
‐ This archive resides on the hub, therefore the list will be the same for all robots
connected to the hub.
‐ There can be more than one version of a package on the local archive.
Web Archive
‐ Displays the list of probe packages on the CA UIM support archive.
‐ You must have a valid login and password for the CA UIM support site to download any
package.
The Local Archive shows all of the probe packages that have been downloaded to the
local hub archive.
You can deploy probes to robots from the local archive.
The Web Archive shows all of the probe packages that can be downloaded from the CA
UIM Support Site.
If you deploy a package from the Web Archive, it is first automatically downloaded to the
Local Archive before it is deployed to the robot.
The Distribution Activity tab displays a log of your probe package distributions along with
the status of each distribution.
Packages can be deployed individually or in groups.
There are now two ways to deploy and configure probes in UIM 8.4.
90% of the most commonly probes used for base monitoring can be deployed using MCS.
Those probes are indicated in the Monitoring Configuration Service Probes chart in the
diagram.
Assigning an MCS profile to a group results in the profile configuration being deployed to
all devices that are group members, and have a deployed robot.
The profiles are applied concurrently to hundreds of target devices. MCS also
automatically deploys probes to target devices as needed.
You’ll use the provided profile types to create profiles. The profile types are designed to
focus on specific system components or functions that can be monitored. You no longer
have to determine which probes to deploy and configure to monitor your devices. You
can always modify profiles as your monitoring needs change.
There are many probes that make up the remaining 10% of the probes needed for
additional monitoring requirements.
These probes will be deployed and configured using the original Admin Console
deployment method of dragging the probe from the archive to a robot.
‐ The target can be an individual robot, a hub, the domain, or an Infrastructure Manager
group (shown in a later module).
‐ When a probe is dropped on a hub, domain, or group, the probe is deployed to
applicable subordinate robots.
Once a probe has been deployed, it will need to be configured.
When an object node is selected in the left‐hand pane, you can configure thresholds,
severity, and enable the Publishing of QoS data on the right‐hand pane.
Some probes gather data from the computer on which they reside (local polling), while
other probes monitor devices external to themselves, such as network switches and
routers (remote polling).
You can monitor the following types of data with CA UIM:
Performance and trend data
‐ Many probes are capable of sending performance and trend data on a periodic basis in
messages that are formatted and known as QoS messages.
‐ These messages normally contain data—response times, network availability, CPU
usage, memory usage, bandwidth utilization, and so on—used for service‐level
monitoring and reporting.
Events and alarms
‐ An event is a known or existing issue or the result of a failure or error in the IT object or
device that causes, or might cause, an interruption or a reduction of the quality of the
service.
‐ You can configure events to trigger an alarm.
Take a moment to think about this question.
If you chose D, you would be correct!
This module showed you how to:
‐ Create USM groups
‐ Identify the types of data to monitor
‐ Complete basic probe deployment and configuration tasks
‐ Perform Discovery and deploy robots
Module 3: Discovery and Robot Deployment 3 ‐ 1
CA UIM provides automated discovery of your network devices and automated probe
deployment to quickly gain insights needed to optimize resources, planning and
investments.
‐ Perform a network discovery
‐ Deploy Robots
‐ CA Unified Infrastructure Management enables you to quickly begin to collect
performance data and events—QoS and alarms—from your environment.
‐ Robots manage the probes that collect monitoring data and perform other functions.
Discovery is the primary method to reduce manual effort while maintaining an inventory
of devices in your managed domain.
‐ In CA Unified Infrastructure Management, you can enable device monitoring and
management on these devices as required, engaging the broad array of probes that
gather QoS data from the monitored devices and generate alarms in response to
threshold breaches.
‐ Components in the CA Unified Infrastructure Management Server automate the
discovery of hosts and devices throughout your network, recording any device within a
discovery range that responds to a request on any configured protocol, including SSH,
WMI, SNMP, and even a simple ICMP ping.
Additionally, within UIM, you are able to define multiple scopes for a discovery agent.
You don’t have to execute then all at the same time, they can be done individually.
Discovery is accomplished by the following standard service probe components:
– The discovery_server probe discovers CA Unified Infrastructure Management
infrastructure components, keeps a list of monitored servers and devices in the
domain, and also finds and communicates with the discovery_agent probes.
– The discovery_agent probe scans the network, collecting as much system information
about discovered devices as possible.
• Some users, such as service providers and those with very large networks, find it
useful to deploy multiple discovery agents in various locations.
• You can divide the discovery of a large network across administrative boundaries so
that specific users have access to different parts of the network or, in situations
where there is no direct connectivity, to devices at a remote site because of firewall
constraints or network‐address translation (NAT).
– The cm_data_import probe processes an XML file that lists information describing
hosts and devices, and adds this information to the device inventory.
• When you run a file‐base import from Discovery Wizard, the cm_data_import probe
carries out the work.
Once the Unified Management Portal (UMP) is installed, the Discovery Wizard starts
automatically and prompts you to configure and run discovery. The wizard allows you to
specify authentication credentials and define IP address ranges to scan. Discovery finds
virtually all connected resources on the network and provides detailed information about
device type, configuration, and asset/inventory data.
You can launch the Discovery Wizard from the Discovery tree or from the Actions menu.
For either method, the wizard opens in the context of the node you launched it from. If
you launch it from a discovery agent node, the Authentication tab is displayed. If you
launch it from a range node, the ranges tab is displayed with the properties of the range
you selected.
Note: After an update of CA Unified Infrastructure Management, you cannot run the
Discovery Wizard if there are existing ranges that define excluded IP addresses. You must
accept the system prompt to delete excluded ranges or remove them manually from the
NIS database before you can run the Discovery Wizard.
The Authentication pages enable you to create, edit, view, and delete authentication
profiles (credentials) for discovery.
An authentication profile contains credentials necessary for the discovery_agent probe to
access and gather information about computer systems and devices in your network.
You can define authentication profiles for the following protocols by clicking on a
protocol tab, then clicking “New Credentials” in the left column, and then populating
the credentials fields.
For details about configuring fields for the other protocols, click the Discovery Help (?)
icon in the upper‐right corner of the Discovery Wizard, which will display the relevant
section of the UMP Product Documentation Guide. This is just one of the many ways that
you can use the online help within CA UIM to quickly understand its features and
functions.
To minimize predictable time‐outs, for each discovery agent, review the assigned ranges
and follow these guidelines:
– To optimize performance and avoid duplicate entries, configure each discovery agent
to discover an exclusive part of the network.
– The discovery agent tries each credential on each IP address and waits for a time‐out
(or success) with every attempt. To speed up a discovery, use a single credential in a
range that has a high probability of immediate success on the nodes in that range.
– When applying an authentication credential to a range, make sure that most, if not all,
devices defined by that range will accept the credential.
– If you include devices that do not respond to requests on any management protocol,
place them in a discovery range with no authentication profiles assigned to the range.
– For SNMP, for a device that accepts only a unique SNMP community string, create a
network range with a single type IP range that specifies the IP address of the device
and assign the corresponding authentication profile to the network range. Also, to
avoid unnecessary authentication traps and alerts, assign only one SNMP
authentication credential per discovery range.
After you finish with the Discovery Wizard, the discovery will run automatically or be set
to run at your chosen date and time.
The Schedule page enables you to schedule a single discovery or recurring discoveries
and to perform the run immediately, in the future, or both.
A scheduled discovery does not interrupt a discovery that is already running.
‐ If at the time a discovery run is scheduled another discovery run is in progress, the
scheduled discovery is ignored.
‐ If you select Run discovery now and a discovery is in progress, the current discovery run
is terminated and the new run is executed.
The Inventory node in the tree view of USM enables you to view computers and devices
that have been discovered on your network
The Inventory section of the tree contains discovery agents, with network ranges under
each discovery agent.
For more information about viewing discovered devices:
– Click the ? icon.
– In the UMP User Documentation Guide, navigate to Discovery  Viewing Discovered
Systems.
‐ Each discovery agent should discover an exclusive part of the network.
‐ Review the assigned range scopes to minimize predictable timeouts.
‐ Use a single credential in a scope that has a high probability of immediate success on
the nodes in that scope to speed up discovery.
‐ If no key icon appears, then check credentials and rerun discovery.
Within UIM, you’re able to deploy a single robot, or deploy robots in bulk .
There are multiple ways to deploy robots:
‐ Basic discovery Automatic Deployment Engine (ADE) push
‐ XML ADE push
‐ Manual install 8080 page (.exe\nimloader)
‐ MSI/RPM package for third party automation
Refer to Product Documentation for more detailed information on each of these
deployment methods.
While there are multiple ways to deploy robots, we’ll take a closer look at ADE, as that is
the most common deployment method. You can also:
‐ Deploy robots to all or selected members of a group
‐ Deploy a robot to a specific system
‐ Do a basic or advanced search for systems to deploy robots to
‐ Import an XML file listing systems to deploy robots to
After you select the systems and start a deployment job, robots are automatically
installed on the selected systems.
To deploy robots automatically, you must have the USM Automatic Robot Installation ACL
permission. Account contact users cannot deploy robots automatically. If you do not have
the USM Automatic Robot Installation ACL permission or if you are an account contact
user, the Deploy Agents tab will not be displayed.
When importing a list of systems from an XML file, however, the credentials are specified
in the XML file and the systems do not need to have known credentials through the
discovery process.
We have provided lab exercises for you to practice deploying robots using ADE, USM and
manual probe deployment.
‐Perform a network discovery
‐ Deploy robots
Examine Monitored Data
Module 4: Examine Monitored Data 4 ‐ 1
CA Unified Infrastructure Management provides UMP portlets—such as USM, Unified
Dashboards, and Performance Report Designer (PRD) charts—that give you insight about
the monitored data appropriate to your role or business context.
— View monitored data
— Examine monitored data in a Performance Report Designer (PRD) chart
— By viewing monitored data in the USM and Unified Dashboards, you can see
information on infrastructure objects.
— By examining monitored data in PRD charts, you will see a visual
representation of QoS data.
Viewing Monitored Data
By viewing monitored data in the USM and Unified
Dashboards, you can see information on infrastructure
objects.
CA Unified Infrastructure Management offers built‐in and easily customizable
views to help you spot trends, optimize resource utilization, and more.
To provide some examples of data in the UMP, you will view data in the following
portlets:
– Device, alarm, metric, and group data in the USM
– Servers in the Unified Dashboards
© 2016 CA. ALL RIGHTS RESERVED.
Module 4: Examine Monitored Data 3 of 14
After collecting QoS data, you can examine various portlets in the UMP to view the
published data.
CA Unified Infrastructure Management offers built‐in and easily customizable views to
help you spot trends, optimize resource utilization, and more.
To provide some examples of data in the UMP, you will view data in the following
portlets:
‐ Device, alarm, metric, and group data in the USM
‐ Servers in the Unified Dashboards
In the main pane, the System tab displays the properties of the device and QoS charts. As
highlighted in the screenshot, you can also view alarm, metric, group, and monitoring
information, and generate a dynamic report.
Notice that there are several icons indicating that there is an alarm associated with this
server, which will be discussed on the next page.
Administrators and other authorized users can view and manage alarms in USM.
You can view alarms for a group or for an individual system. Authorized users can assign
and acknowledge alarms. Administrators can set alarms to invisible so that they are
hidden from other users, and can view invisible alarms.
Alarm data is summarized in a bar chart, and alarms can be displayed in a list or a table.
You can filter alarms or change the way the data is sorted. You can also view a graph of
the associated performance metric, if there is one, and view alarm history.
The Alarm View displays all current alarms, including those that are not associated with a
group or a system.
You can view additional information from the Metrics and Groups tabs.
Groups are lists of computer systems. Administrators can create groups to assign the
same monitoring template or report template to multiple computer systems.
The UMP comes with predefined views called Unified Dashboards.
To view the drilldown report for a server, for a particular name, click on the name.
To view the drilldown report for a metric, double‐click the metric.
When you generate a drilldown report, the report opens in its own page.
Now that you have examined monitored data in several portlets, you will create a PRD
chart to view QoS data in a visual format.
PRD charts can be used for one‐off (ad‐hoc) reporting.
Here, we should emphasize the multi‐tenant nature of the tool, that is, that ad‐hoc
reports you build for one customer will not be usable by another. This is where filters
come in. We’ll cover more about filters later on in the course.
PRD charts enable you to:
– Drag charts between rows or drag a data series from one chart to another
– Choose the chart format: line, area, or column chart
– Plot only the data that matches specified filters on the chart
– Change the source host or target of the data
– Save a set of charts as a report to print or to view later
‐ View monitored data
‐ Examine monitored data in a Performance Report Designer (PRD) chart
‐ Configure Basic Alarm Notifications
Module 5: Basic Alarm Notifications 5 ‐ 1
CA Unified Infrastructure Management provides UMP portlets—such as USM, Unified
Dashboards, and Performance Report Designer (PRD) charts—that give you insight about
the monitored data appropriate to your role or business context.
— Configure the emailgtw probe
— Activate AO logging
— By configuring the email gateway (emailgtw) probe in the Infrastructure
Manager, you set the email gateway target for the NAS operation.
— After activating AO logging, you can track NAS activities by enabling audit
logging.
— Validate auto‐acknowledgement
— Build an AO profile to send emails on alarms
— By validating auto‐acknowledgement, you can confirm that CA Unified
Infrastructure Management is processing ‘clear’ alarms.
— By building AO profiles, you can automate alarm message processing
instead of solely relying on manual assignment.
— Define maintenance schedules
— Maintenance schedules allow you to temporarily suppress alarms for
devices while they are undergoing maintenance.
Configuring the emailgtw probe in the Infrastructure Manager sets the email gateway
target for the NAS operation.
The CA UIM Email Gateway probe converts alarms into emails, according to the
predefined criteria for alarms, such as, severity, origin, and time, that are set in the CA
UIM Alarm Server.
On Windows robots, you can use either SMTP server or Exchange server to send emails.
On robots on other operating systems, you can only use SMTP to send emails.
The probe collects these emails at the specified interval and sends them to mail
addresses defined in the profiles.
From the Admin Console portlet, download the emailgtw probe and deploy it to a robot.
Configuring an emailgtw probe includes setting up a profile and applying an email
template.
The emailgtw probe is configured using the Admin Console.
On the Mail Server node, specify the primary and, optionally, the secondary email server.
Configuring an emailgtw probe includes setting up a profile and applying an email
template.
The emailgtw probe does not generate any QoS metrics. Therefore, there are no probe
checkpoint metrics to be configured for this probe.
The profile is used to send emails to a user, a group of users, or a role.
If you select Report Recipients, the profile will receive an alarm report at the interval that
is specified on the top level emailgtw node.
You can use the default email template text from the template.html file or create a
custom template file to suit your specific requirement.
The emailgtw probe can also be configured using the Infrastructure Manager.
To audit AO events, activate AO logging and set the interval on the Auto‐Operator tab in
the NAS probe.
From the Status tab, select Enable Activity Logging from Activity Log > Preferences and
then select any or all logging preferences.
By validating auto‐acknowledgement, you can confirm that CA UIM is processing ‘clear’
alarms.
To confirm that auto‐acknowledgement is performing correctly, send a test message.
For the purposes of notification, you build an AO profile that sends appropriate alarm
data to the emailgtw probe.
Setting up an AO profile requires an:
– Action type
• What response to take
– Action mode
• When to take the response
– Adequate filter
• How to react to the alarm (Does the alarm match the criteria?)
Additionally, you can apply and view operating periods and schedules.
A few of the more common actions that an AO profile enables you to take are:
‐ Route alarms to people automatically instead of relying on a manual assignment
process
‐ Send emails on specific alarms
‐ Execute a script
Maintenance schedules allow you to temporarily suppress alarms for devices while they
are undergoing maintenance.
Maintenance schedules are managed from the Maintenance tab.
The Maintenance tab is available when a group is selected in USM.
The Maintenance Schedule definition window allows you to identify the frequency,
duration, and start time.
To assign a device or group of devices to a maintenance schedule, click the icon that is to
the right of the group or device name and drag it to the schedule.
Ad hoc maintenance schedules for a single device can be easily created.
Alarms are suppressed during the maintenance period.
‐ Configure the emailgtw probe
‐ Activate AO logging
‐ Validate auto‐acknowledgement
‐ Build an AO profile to send emails on alarms
‐ Extend monitoring capabilities
Module 6: Advanced Monitoring Administration 6 ‐ 1
To discover more information about your IT environment, you need to extend the
monitoring capabilities of CA Unified Infrastructure Management through the
configuration of various probes.
CA Unified Infrastructure Management v8.4: System Admin Foundations 200
‐ Administer MCS
‐ Deploy & configure probes
‐ Most probe deployment and configuration should be handled through MCS.
‐ To monitor devices, probes must be deployed to robots.
‐ To extend specific monitoring capabilities of UIM not addressed by MCS, you must
configure probes through IM or Admin Console.
‐ Identify the benefits of probe Packages and SuperPackages
‐ Define and configure probe Packages and SuperPackages
‐ Using probe Packages and SuperPackages, you can establish monitoring templates used
to standardize monitoring across the enterprise.
‐ Packages and SuperPackages enable you
to deploy probes, custom probe configurations, and sets of probes to the monitoring
infrastructure in a single operation.
Most of the commonly used probes can be deployed and configured using the Monitoring
Configuration Service. Let’s look a typically scenario where you would want to use MCS:
You want to monitor computer uptime and usage of processing resources for devices in your
environment, but you’re not sure which probe to use. You’d like to spend as little time as possible
configuring metrics and alarms, and you want to start collecting data immediately. You also want
to test your configuration on a single device in a test environment before you roll out the
configuration to your production environment.
You can accomplish all of this by using MCS to create configuration profiles. Once you create
configuration profiles, MCS applies the profiles to target devices or groups. MCS can apply the
same set of configuration profiles to many devices and groups, thus providing consistent
monitoring across your environment.
We’ll begin in the Unified Service Manager (USM) and expand to see the Windows group to see
its member devices. You can create configuration profiles at the group or device level.
Remember, it’s always recommended to create and deploy a configuration profile to a single
device first before rolling out the configuration to your production environment.
Let’s access MCS from the Monitoring tab. This first thing we see are profile types for the
selected device in the middle pane. You use profile types to create configuration.
Each profile type lets you configure different monitoring metrics and alarms. The profile
type name indicates the type of monitoring that you can configure. The setup profile
types at the bottom of the list, lets you configure general monitoring settings, such as log
level for different probes.
Let’s say we want to start monitoring CPU usage for the selected device. Looking at the
profile types, we decide that CPU Monitor seems to be the profile type we want. When a
profile type is selected, MCS tries to detect a cdm probe running on the target device. If
it isn’t, a message appears indicating that the probe is not installed. Click Yes to confirm
the installation and MCS automatically deploys the cdm probe.
Then the configuration field appears in the right pane. Notice CPU Monitoring remains
highlighted. This helps us keep track of the type of monitoring that we’re configuring.
Once the configuration is complete, click the Create button to create a new CPU Monitor
configuration profile.
Then the configuration field appears in the right pane. Notice CPU Monitoring remains
highlighted. This helps us keep track of the type of monitoring that we’re configuring.
Once the configuration is complete, click the Create button to create a new CPU Monitor
configuration profile.
Refer to the Product Documentation for more detailed information about the Monitoring
Configuration Service (mon_config_service) probe.
Watch more about how to use MCS for group and device monitoring:
http://bit.ly/29t7V2L
‐ Device Monitoring Configuration with MCS
‐ Group Monitoring Configuration with MCS
We’ve just received an email from the SQL Server administration group requesting
monitoring requirements for SQL Servers.
As you can see, we’re being asked to configure monitoring requirements for:
‐ buffer cache hit ratio
‐ database availability
‐ database size
‐ active connection ratios
‐ allocated space
There is also a requirement to poll the database every 5 minutes, the ability to see the
values on a dashboard, and alarm notifications to be setup.
The next recommended step would be to update the Monitoring Governance worksheet
to ensure these requirements are documented, to not only achieve better planning, but
to help reduce the overall effort required to maintain the solution.
This will also become part of change management.
You can see that a new tab has been created for MS SQL Server Monitoring, and that the
requirements the database administrator had requested, have been entered.
In the next lab exercise, you will use these values to configure the MS SQL Server
monitoring using MCS.
Here is quick reference matrix to help determine the best probe configuration workflow
to implement within your environment:
‐ Use a profile based approach with MCS, if you’re not sure which probe to use, if you’d
like to spend as little time as possible configuring metrics and alarms, and you want to
start collecting data immediately.
‐ Use IM or AC for those individual probes not included within the Monitoring
Configuration Service.
‐ Configuring Dynamic Thresholds is only available with Admin Console.
‐ All probes can be configured through IM and AC.
‐ MCS and AC are web‐based consoles, while IM is a Fat Client, and Windows only.
‐ SuperPackages are only available using IM.
As we’ve mentioned, 90% of the workflow scenarios are delivered thru MCS, but some
monitoring scenarios might need one of many probes not covered by MCS, so it’s
imperative to learn probe deployment using Infrastructure Manager and Admin Console.
Regardless of the probe deployment method, probes must be deployed to robots.
Probe deployment:
‐ Copies the probe from the archive to robot
‐ Creates the probe directory on the robot file system
‐ Creates a .cfg file from the .cfx file located in the probe package
‐ Does any dependency checking specified in the probe package
‐ Does any requested pre/post processing specified in the probe package
For probes not deployed with MCS, you will deploy probes by dragging the probe from
the archive to a target.
‐ The target can be an individual robot, a hub, the domain, or an Infrastructure Manager
group.
‐ When a probe is dropped on a hub, domain, or group, the probe is deployed to
applicable subordinate robots.
‐To deploy a fresh instance of a probe binary, clear Update Only.
The following tools are also available to configure probes:
‐ Infrastructure Manager
‐ Admin Console
‐ The configuration capability is currently limited to a subset of probes.
For a probe listing, in the online CA UIM documentation, see:
CA UIM Solution › Probe Products › Probe Library for Admin Console
We’ll use the cmd probe for our description of the Infrastructure Manager, but cdm 5.71‐
MC will be the cdm probe available through MCS. You will notice similarities and
correlation between IM and MCS, but not everything will be configurable through MCS.
You are able to use IM for full configuration, if needed.
Refer to the Probe Configuration Best Practices to determine the best way to deploy the
cdm probe for your environment.
Within Infrastructure Manager:
‐ configure CPU, disk and memory properties in the Control properties area on the Setup
tab.
‐ Configure CPU, disk and memory alarm thresholds, and view their usage and activity, on
the Status tab.
On the Advanced tab, specify the QoS data you want to publish.
The QoS objects you select will be displayed in USM device‐level views, and also in other
dashboards and reports you create.
On the Custom tab, you can add profiles for CPU, disk, and memory.
Use the Net Connect probe to monitor a collection of host and TCP service profiles for
connection responses through ICMP and Telnet connections to specific ports.
The probe is used to assure the robot has access to an IP address and/or service port,
such as 25 (SMTP).
To monitor connection responses, first set up a profile for the host you want to monitor.
After configuring a host profile, you can add services to monitor.
Each profile:
‐ Uses the default settings unless overridden by profile settings
‐ Can be configured independently with unique interval and service time‐out values
‐ Alarms can be generated when the defined thresholds are breached.
Use the URL Response probe to monitor the access to URLs, as well as response times for
various connection points, e.g., DNS resolution time, TCP connect time, and so on.
Then, select publishing data for the metrics you want to monitor.
The Baseline Engine allows users to baseline QOS metrics and configure dynamic and
static thresholds against those baselines.
‐ The Baseline Engine should be deployed on lowest tier hubs if they exist, but can be
deployed on main hub based on scale.
Baselines and thresholds must be configured explicitly.
‐Using the Admin Console probe configuration UI for supported probes
‐ The configuration options appear within each QOS monitor definition block
that has an option to Publish Data
‐ Using the command line for probes that are not yet supported by the Admin Console UI
At the release of CA Unified Infrastructure Management v8, Baseline Engine support of
static thresholds is limited to the AWS, MQ Series, and ICMP probes.
Take a moment to review these command line configurations used to set a baseline and
threshold.
Notice that these commands should be run from <baseline_engine_dir>.
The QOS metric id required by the baseline and threshold commands can be identified
using DrNimbus.
Here are the steps to
1. Select Publish Data. This enables the Compute Baseline selection.
2. Select Compute Baseline. This enables the Dynamic Alarm Threshold selection list.
3. Select Dynamic or Static. Doing so will expand the selected threshold type so that it
can be configured.
When configuring dynamic thresholds, select the Algorithm, Direction, assign threshold
Values and assign custom subsystem ids if desired.
When choosing an Algorithm, the following applies:
• Scalar ‐ Each threshold is set an amount from the baseline that is a constant value.
• Percent ‐ Each threshold is set an amount from the baseline that is a percentage of the
baseline.
• Standard Deviation ‐ Each threshold is set an amount from the baseline that is a
measure of the variation in the data used to compute the baseline. A large standard
deviation indicates that the data points are far from the computed baseline. A small
standard deviation indicates that they are clustered closely around the computed
baseline.
When choosing a direction, the following applies:
• Increasing ‐ An alarm occurs when the metric increases past the set threshold.
• Decreasing ‐ An alarm occurs when the metric falls below the set threshold.
When configuring static alarm thresholds, select the Direction, assign threshold values
and assign custom subsystem ids if desired.
When choosing a direction, the following applies:
• Increasing ‐ An alarm occurs when the metric increases past the set threshold.
• Decreasing ‐ An alarm occurs when the metric falls below the set threshold.
The baseline engine subscribes to the QOS_MESSAGE queue. This means that every QOS
message flows through the baseline engine.
For every QOS, the baseline engine:
1.Determines if the QOS is being baselined
‐ If yes, stores the value in file cache
‐ If no, ignores the QOS message
2. Determines if dynamic thresholds are configured for the QOS
‐ If yes, the QOS value is checked against the configured thresholds and alarms are
generated as necessary
‐ Sample Alarm: “QOS_CPU_USAGE = 7.76 on NMSHub has crossed the warning
threshold of baseline + 9% (baseline = 6.85)”
At the top of each hour the baseline engine calculates the average for each metric and
publishes a new QOS message called “QOS_BASELINE”.
Using probe Packages and SuperPackages, you can establish monitoring templates used
to standardize monitoring across the enterprise. Packages simplify the configuration of
probe monitoring through the use of configuration file templates.
These templates extend the underlying traditional CA Unified Infrastructure Management
individual probe configuration and deployment.
‐ You create monitoring templates by assigning one or more metric monitors such as CPU
usage, ping response time, or URL monitoring.
‐ Monitoring templates enable you to configure a monitor one time and use it multiple
times across your environment.
‐ Monitor settings include thresholds, data collection intervals, and so on.
‐ When a Package or SuperPackage is deployed to a robot, probes are automatically
pushed to robots with appropriate configuration settings for each monitor.
NOTE:
Packages are stored in both IM and AC archives; Superpackages only in IM. You can
deploy SuperPackages from either interface, but only IM allows editing.
Packages and SuperPackages enable you to deploy probes, custom probe configurations,
and sets of probes to the monitoring infrastructure in a single operation.
Probe packages are stored in the archive and contain probe binaries and/or
configurations for one or more host environments.
When you work with packages, you will modify the CFX file of the package that stores the
underlying configuration of the probes. Over the next pages, you will see examples of this
configuration modification.
SuperPackages are defined and configured using the Archive node in Infrastructure
Manager.
This is basically where the parts are stored. You only administer superpackages thru IM.
Base packages contain binaries and default configurations for a single probe as provided
by CA Technologies through the installation media or the Internet archive.
Configuration Only packages contain custom configurations for a single probe as defined
by users to satisfy their monitoring requirements.
‐ Configuration Only packages must be deployed using Infrastructure Manager.
Drag a configured probe from a robot to an archive, rename it, and select Configuration
Only.
The Configuration Only package is then added to the archive.
Within a Configuration Only package, you can edit the CFX file to limit the configuration
attributes that it contains.
Take a moment to review the CFX Syntax Directives and an example.
‐ Administer MCS
‐ Deploy probes
‐ Configure probes using IM and AC
‐ Identify the benefits of probe Packages and SuperPackages
‐ Define and configure probe Packages and SuperPackages
‐ Perform Advanced Hub and Robot Configuration
Module 7: Advanced Hub and Robot Configuration 7 ‐ 1
Through the deployment of multiple hubs in Infrastructure Manager, you can scale the CA
Unified Infrastructure Management architecture to meet your business needs.
‐ Plan hub‐to‐hub communications
‐ Implement hub‐to‐hub communications
‐ To properly plan hub‐to‐hub communication to ensure that all objectives are met.
‐ To properly scale CA Unified Infrastructure Management, you need to deploy additional
hubs and implement hub‐to‐hub communications.
To properly plan hub‐to‐hub communications to ensure all objectives are met:
1. Decide on a network communication method:
‐ Basic: Broadcast, simple network connection, no problems or block
‐ Minimal: Static hubs, for traversing subnet breaks
‐ Advanced: Hub‐to‐hub tunnels, firewalls, WAN, DMZ, and so on
2. Decide on a queue method:
‐ Post: Less setup, fast and efficient, but no acknowledgment
of delivery
‐ Get/attach: Additional overhead, greater efficacy
There are some additional hub‐to –hub communication factors to remember.
Hub limits for tunnels/subscribers:
We recommended 25 to 50 for Windows‐based systems and 50 to 100 for UNIX‐ based
systems
• Subscriber limits will depend on your combination of queues and tunnels.
• When you mix and match, you can exceed the number of queues but you need to
reduce the number of tunnels, or the reverse.
• In practice, the limits on the tunnels are most important.
Redundancy concerns
• Make sure a failover does not exceed the recommended number of subscribers.
Queue subjects/bulk sizing
• Match queue needs, whether split or combined, with subscriber limits.
• Leave bulk sizing at the default configuration until you are presented with a problem
such as a queue that is not clearing.
Secondary hubs are created after the CA Unified Infrastructure Management server
software is installed. They can be created or removed as needed to meet the needs of
your IT environment.
Multi‐tenancy is central to CA UIM and is based on the origin of a particular QoS metric
or alarm message.
The origin is set by default at the hub level, but can be overridden at the robot level by
manually setting the origin of the robot in the controller probe configuration.
Basically, a hub is just a robot running the hub probe, which then acts like a post office.
Permanent queues are stored in the local hub database and survive a hub restart. This
type of queue helps ensure that messages are delivered even if the receiver is down
when a message is generated. For example, with the NAS probe, if the hub running this
service goes down and then comes back up, it fetches all alarms generated while it was
down. This ensures no alarms are lost.
Temporary queues are used for less‐critical communication paths. For example, with the
UMP alarm viewer portlet, when a user starts UMP, the portlet subscribes to alarm
messages and a temporary queue is created. Messages are forwarded to this queue as
long as the alarm viewer is active. When the viewer is closed, the queue is removed.
Message queues are set up in two ways:
– Automatically: In most situations, queues are a transparent part of the infrastructure
and are set up automatically. Permanent queues are set up between hubs during
installation. Temporary queues are created as needed.
– Manually: You can manually create queues in Infrastructure Manager. For example, if
you have multiple secondary hubs, you might set up a queue to send all alarms to a
specific secondary hub.
Here are the hub‐to‐hub queue methods.
The post method:
• Can traverse different domains
• Can be set up to forward copies of messages
• Cannot be used to confirm receipt of message
• Cannot be used to failover between systems
With the get/attach method, you:
• Can confirm receipt of message
• Can only have one active get/attach pair, but can have multiple dormant get queues
configured
• Cannot forward more than one set of messages to one destination
Both, the post and get/attach methods ,provide guaranteed delivery because both will
queue messages if the downstream hub is not available.
With the get/attach method, you are notified if the downstream hub is not available.
• This occurs at the get end.
With the post method, you are not notified if the downstream hub is not available.
The post method is needed for cross‐domain queues.
• Cross‐domain queues are only used in extreme cases and are not recommended.
Hubs can communicate in one of three ways:
• Broadcast
• Static hubs
• Hub‐to‐hub tunnels
Tunnels are VPN‐like connections to communicate through firewalls over a single port
(48003).
An SSH tunnel can be set up between two hubs that are separated by a firewall. The
tunnel sets up a VPN connection between the two hubs. All requests and messages are
routed over the tunnel and dispatched on the other side. This routing is transparent to
users.
The DMZ wizard enables you to easily set up these tunnels. You can create tunnels
between any CA Unified Infrastructure Management hubs.
It’s important to remember not use static hubs when using tunnels.
Using a tunnel is most effective in the following scenarios:
• Monitoring computers outside the internal LAN
‐ When the LANs are separated by firewalls
• Static hubs having the same IP address due to the existence of overlapping IP
addresses
• Using NAT connectivity over the Internet
• Using encryption over public network segments
‐ Plan hub‐to‐hub communications
‐ Implement hub‐to‐hub communications
Perform advanced alarm configuration
Module 8: Advanced Alarm Configuration 8 ‐ 1
Advanced Alarm Configuration
CA Unified Infrastructure Management provides you with tools and utilities to apply the
advanced capabilities of AO to perform complex alarm monitoring. This module shows
you how to use these tools and utilities to perform advanced automation to reduce
manual intervention.
CA Unified Infrastructure Management: System Admin Foundations 200
‐ Build an AO profile
‐ Enhance alarm messages using the alarm_enrichment probe
‐ Using Auto Operators, you can generate new alarm messages based on existing alerts,
execute scripts, and set triggers for alarm correlation.
‐ By enhancing alarm messages, you can meet sub‐robot multi‐tenancy requirements.
‐ Perform advanced alarm processing
‐ Understand the new Event Management Service (EMS) basics
‐ You can change the underlying alarm behavior of CA Unified Infrastructure
Management through advanced alarm processing.
‐ You can more easily identify and rapidly resolve infrastructure faults.
First, let’s talk about the Alarm Server, known as the nas, at a high level.
The Alarm Server (nas) stores and administers alarm messages for the UIM.
The nas package contains two probes:
‐ alarm_enrichment
‐ nas
The alarm_enrichment and nas probes are packaged, installed and configured as a single
unit as part of the UIM product installation. They will display in your system archive as
separate probes, however they are configured using the nas probe configuration and
saved in the nas.cfg file.
The alarm_enrichment probe is a pre‐processor probe for the nas probe.
The nas probe is a service probe and acts upon the incoming alarm message, received
from the alarm_enrichment probe, by storing information about the message into a
database.
The first thing we’ll do is configure the nas probe by creating an Auto‐Operator profile.
Setting up an AO profile requires an:
Action type
‐ What response to take
Action mode
‐ When to take the response
Adequate filter
‐ Which alarms should this AO profile respond to
Using Patterns and RegEx in Matching Criteria Fields
Using Patterns and RegEx in Matching Criteria Fields
All matching criteria fields accept the following:
All matching criteria fields accept the following:
– Literal strings
— Literal strings
– Simple pattern matching using the * wildcard character
— Simple pattern matching using the * wildcard character
– Formal RegEx
— Formal RegEx
 To force recognition of RegEx, encapsulate the expression in “/”.
• To force recognition of RegEx, encapsulate the expression in “/”.
All matching criteria fields, with the exception of the message field, can also
All matching criteria fields, with the exception of the message field, can also contain
contain comma‐separated or pipe‐separated values.
comma‐separated or pipe‐separated values.
– These values can be a mix of literal strings, pattern matching, and RegEx.
— These values can be a mix of literal strings, pattern matching, and RegEx.
– Example: robot1, robot2*, /.robot./
— Example: robot1, robot2*, /.robot./
Values That Match This Example Additional Examples
robot1 first criteria abc,def Interpreted as two patterns
robot2 second criteria abc def Interpreted as two patterns
robot2xyz second criteria abc|def Interpreted as one pattern
myrobottest third criteria
Module I: Introduction
Module 8: Advanced Alarm Configuration 6
8 of 27
of 47
Pressing F1 in the matching criteria fields, except for the Message field, displays the
Select Source screen. This screen displays a list of parameters retrieved from the
transaction summary table. This table contains entries for alarms, such as hostname and
source origin, that were processed recently.
Pressing F2 in a matching criteria field displays the Pattern and Regular Expression
Validator screen. Type the string you want to use as the target string and the
pattern/regular expression you want to use. Click the Test button and verify that the
output is "Expression matches the target string". When you click OK, the pattern/regular
expression will be inserted into the field.
The Operating Period tab enables administrators to specify when the profile will be
active.
‐ If left totally gray, the profile is always active.
‐ To limit the hours for the profile, select the cells to define the required active period.
You can also select cells using the available shortcut menu.
Next, we’ll configure the alarm_enrichment probe:
– Is a pre‐processor probe for the NAS probe
• It attaches itself to a permanent queue and receives alarm messages distributed by
the hub.
– Corrects the origin value on alarms and QoS data by looking up the correct value in a
user‐defined database table.
The messages flow into the alarm_enrichment probe, where alarm storms are detected,
and messages are enriched with additional information read from external data sources,
using a Configuration Management Database (CMDB).
Note: Alarm enrichment has 2 parts; alarm enrichment updates the alarm and
qos_processor updates the data.
Multi‐Tenancy
The Problem
In a multi‐tenant environment, the default method of identifying the source for
alarms and QoS data is the value assigned to the origin field.
– The origin is configured at hub or robot level.
– Some users need the origin to be assigned at the probe or profile level.
For example:
 A service provider needs to monitor URLs for multiple customers from the same
robot.
 A service provider has switches on which interfaces belong to different customers.
Module 8: Advanced Alarm Configuration 10 of 27
Multi‐tenant environments present a problem.
In a multi‐tenant environment, the default method of identifying the source for alarms
and QoS data is the value assigned to the origin field.
‐ The origin is configured at hub or robot level.
‐ Some users need the origin to be assigned at the probe or profile level.
For example:
‐ A service provider needs to monitor URLs for multiple customers from the same robot.
‐ A service provider has switches on which interfaces belong to different customers.
Multi‐Tenancy
The Solution
Alarm enrichment:
– Looks for a match to the alarm message source/target value in lookup tables
retrieved from any SQL/JDBC‐compliant CMDB
 If a match is found, the alarm message origin is replaced with the new value
specified in the table.
 If no match is found, the alarm message origin is not changed.
Note: Alarm enrichment can be used to update other alarm
message field values in addition to the origin field.
The solution is Alarm enrichment:
‐ Looks for a match to the alarm message source/target value in lookup tables retrieved
from any SQL/JDBC‐compliant CMDB
‐ If a match is found, the alarm message origin is replaced with the new value
specified in the table.
‐ If no match is found, the alarm message origin is not changed.
Note: Alarm enrichment can be used to update other alarm message field values in
addition to the origin field.
Here is a look at an alarm before and after alarm enrichment.
Even though all of the data is coming from the same place, we’re looking at each alarm
that comes through in that stream of alarms, and if it meets certain criteria, the tag will
be changed.
In this case, subject is changed from alarm to alarm 2, and the origin tag from Desktop
to RoboRemkoORigin.
The qos_processor subscribes to the qos messages on the message bus to store QoS

messages for processing. and automatically updates messages based on the alarm
enrichment.
This diagram shows the architecture and how it works.
‐ New messages are stored in a cache.
‐ Subsequent messages matching records in the cache on qos, source and target fields
are discarded.
‐ The processor does not need to modify every message, just primary entries in the
S_QOS_DATA table.
On an interval, data from the cache is processed using a Ruby script and changes are
written to the S_QOS_DATA table.
‐ The default is every 60 minutes.
When the S_QOS_DATA table entry in modified, the original origin is saved in the
nimorigin column.
This is a basic script that is just pulling data from the S_QOS_DATA table and is not doing
a lookup from a customer table.
For the net_connect probe, the script uses the first three characters from the qos target

field as the new origin.
For the rsp probe, the script uses the first three characters of the source field.
qos_processor
Database Lookup Script – Part 1
The first part of the script sets the requirements and the variables that need to be
modified to match the customer environment.
# Filename: enrichment.rb
# QOS_Processor Ruby Script called by Script_Runner.rb
#
require 'java'
if File.exist? "lib/sqljdbc4-4.0.jar"
require “./lib/sqljdbc4-4.0.jar"
#==Change the following variables according to your needs==#
ip="xxx.xxx.xxx.xxx"
port="1433"
db=“CA_UIM"
driver="jdbc:sqlserver://"
driverClass="com.microsoft.sqlserver.jdbc.SQLServerDriver"
user="sa"
passwd="YourDBPassword"
#==========================================================#
The first part of the database lookup script sets the requirements and the variables that
need to be modified to match the customer environment.
qos_processor
Database Lookup Script – Part 2
The second part of the script executes a query against the CA_UIM database to match
the qos source ($monitor.source) from the S_QOS_DATA table to either a device name
or IP address from the CustomerDB table.
– If a match is found, it checks to see if the qos metric is from the cdm or rsp probe.
– If the metric is from one of these probes, it will use the customer string from the db
lookup as the new origin ($monitor.origin).
begin
dbserver=ip+":"+port
url = driver+dbserver
java.lang.Class.forName(driverClass, true,
java.lang.Thread.currentThread.getContextClassLoader)
$logger.info("About to connect...")
con = java.sql.DriverManager.getConnection(url,user,passwd);
if con
$logger.info("Connection good to "+dbserver)
else
$logger.info("Connection failed")
end
The second part of the script executes a query against the CA_UIM database to match
the qos source ($monitor.source) from the S_QOS_DATA table to either a device name or
IP address from the CustomerDB table.
‐ If a match is found, it checks to see if the qos metric is from the cdm or rsp probe.
‐ If the metric is from one of these probes, it will use the customer string from the db
lookup as the new origin ($monitor.origin).
qos_processor
Database Lookup Script – Part 2 continued
b = con.create_statement
rs=b.execute_query("select customer from CA_UIM.dbo.CustomerDB where
devicename='"+$monitor.source+"' or ip='"+$monitor.source+"'")
while(rs.next())
if ($monitor.probe == 'cdm') || ($monitor.probe == 'rsp')
if(!$monitor.origin.nil?)
$logger.info("Probe: " + $monitor.probe + "Old Origin:
"+$monitor.origin)
value=rs.getString("customer")
$monitor.origin=value
$logger.info("Probe: " + $monitor.probe + "New Origin:
"+$monitor.origin)
end
end
end
rs.close
con.close
end
else
$logger.info("No jar file found ! Make sure you have lib/sqljdbc4-4.0.jar
file.")
end
This is the remainder of the script.
Triggers enable administrators to sort alarm messages based on properties set for the
trigger. This means that alarms matching the criteria defined for the trigger will not be
handled by an AO profile.
Triggers are set up to fire much like matching criteria in the AO profile.
– A trigger by itself, can only be True or False if it matches an Alarm.
– You can define multiple triggers, which can then be used to provide event correlation.
Pre‐processing rules enable you to create a filter and exclude an alarm from processing
or mark an alarm as invisible if a matching alarm is received.
An invisible alarm will not be seen by anyone whose ACL does not have the View Invisible
Alarms permission check box selected.
The Schedule dialog enables you to select the scheduling mode, operation, and starting
and ending dates and times. The screenshot shows that the Activate Profile operation is
set to begin on April 13 at 4:07 pm and end about an hour later on the next day.
This involves creating a script to check for correlations between the messages of the
newest alarm and a trigger list of alarms. If a match is found, the script will create a new
alarm informing you of the correlation.
What is EMS? It’s the new Event Management Service now available in UIM 8.4.
It’s a UIM infrastructure probe that is intended to rapidly identify and resolve
infrastructure fault. NAS is still part of UIM, and at this point, is still considered the
primary alarm processing service.
Why would you want to use EMS over NAS?
‐ EMS provides the ability to support events outside of UIM.
‐ It also provides a more flexible way to configure when alarms are raised, which gives
more power to writing rules to determine in what conditions an alarm would be
raised.
‐ EMS will send events over the bus, that could lead to actions, but not necessarily raise
alarms. Every alarm is an event, but not every event needs to be an alarm.
‐ You are now able to create custom interfaces to access your alarms, using APIs.
‐ Traceability will help you quickly understand what led to the raising of the alarm.
Let’s take a look at the new architecture.
Within UIM there is now a new EMS Client Java API. All access to alarms in USM,
is now going this API.
Formerly, the USM would make SQL queries into the NIS database, seen at the
lower left of the diagram. Now, USM is going through the EMS Client Java API.
This API works with both NAS and EMS, which means that if you did not install
EMS, you will still be getting these new layers. Another feature is a localization
service.
Prior, all of the localization was done within the USM user interface. With this
new service, localization occurs below the API layer. For example, if you are
writing code to query the API, you can now localize the message that you receive.
(continued)
The NIS DB still exists and the alarm tables are still there, but if you were to write
a customization to UIM and go directly to the NIS DB to query those alarms, you
will not be able to access alarms that might be routed through the EMS. They are
no longer stored in the NIS database, but are now in their own Persistent Data
Store with EMS.
Remember, even though there is no change to the NAS, if you mix NAS and EMS
by running them in parallel, which is perfectly fine to do, you must query the EMS
to see all of the alarms. If you only query the NAS, it could appear that you are
missing some alarms. They are not missing, they are stored elsewhere.
The existing REST services for alarms still exist, and work with both NAS and EMS.
The Alarm Routing Service is the most important thing to know about EMS.
If you install EMS with UIM in version 8.4, you will also get the Alarm Routing
Service. Currently by default, when the Alarm Routing Service is installed, all of
the alarms are routed through the Nimsoft Alarm Server. No alarms would be
going through the EMS.
However, there is a routing service that can be configured to enable the use of
alarm properties, such as, the Probe ID or the Source IP address, and route those
specific alarms to EMS. This feature allows you to experience EMS to determine
which alarms you want EMS to manage. This can also be done in a Production
environment.
This diagram shows what is available with EMS in UIM 8.4.
Probes will still raise alarms. Those alarms will go through the Legacy Alarm
Manager automatically if they are going into EMS.
The Legacy Alarm Manager would then create events, which can then be
processed by rules and go to the Alarm Manager. These can be parsed by alarm
rules and then stored in the Persistent Data Store of EMS.
Emails or SMS message actions can be done through the Alarm Manager.
This section was to introduce you to the new Event Management Service. If you
want to deploy this service, you should refer to the detailed steps in the ems
Probe Deployment and Configuration documentation found under Deploy the
Alarm Routing Service.
General things to remember:
‐ By default, when the alarm manager is installed, all alarm messages will ONLY
be managed by the NAS.
‐ If you want to use the features available in EMS for processing alarms, you will
need to route alarms to the EMS.
‐ Define filters based on alarm properties to determine which alarm service will
be responsible for processing alarms that meet the filter criteria.
(continued)
Easy Mistakes to make:
‐ It is possible to route one alarm to both NAS and EMS. In those situations, you
will see duplicate alarms in USM! This can be resolved by modifying the
routing configuration to send alarms only to either NAS or EMS, not both.
‐ When alarms are routed to the EMS for processing, they are no longer listed in
the NIS DB. Therefore, direct SQL queries into the NIS DB will not return alarms
that are in the internal EMS data store. This can be resolved by using the alarm
REST services instead of SQL queries.
A rules editor will not be available in EMS 8.4. Instead, all EMS event and alarm
rules are stored in files. There are a default set of rules that cannot be edited, but
you are able to add new rules.
Detailed instructions for editing the files is available in the documentation under
Creating Event and Alarm Rules with the XML Rule Catalogs.
The documentation contains excellent examples of common rules. Some of the
examples include:
‐ Clear an Alarm
‐ Escalate an Alarm Severity
‐ Enrich an Alarm from a CSV File
‐ Raise an Alarm from an Event Message
‐ Set Alarm and Event Properties
‐ Send an Email or Text Message
EMS diagnostics is something that you can keep track of by using this table to
reference the diagnostic logs.
The primary log is in the probes/service/ems.log. This will provide information
about:
‐ Event processing across the Legacy Alarm Manager, Event Manager and Alarm
Manager
‐ Rule configuration details
‐ Rule processing
‐ Rule execution and scripting errors
‐ Alarm lifecycle management
‐ Pub/sub messages
‐ Read and write of EMS alarms
(continued)
EMS also uses Trellis, so there are some things that might show up in the trellis
log. If you reference the EMS architecture diagram, you’ll see that Trellis is used
to access the NAS. If there is an issue where NAS alarms aren’t being displayed,
you can Read and Write NAS alarms via the NIS DB. This will also provide
information about the DB schema migration of the annotations table to help
debug what might be occurring.
The Alarm Routing Service is also logged inside Trellis. Any alarm routing or
configuration issues are provided within this log.
Again, Be sure to refer to the CA UIM Probe documentation wiki for detailed
information prior to deploying and configuring EMS into your environment.
‐ Build an AO profile
‐ Enhance alarm messages using the alarm_enrichment probe
‐ Perform advanced alarm processing
‐ Perform SLM tasks
Module 9: Perform SLM Tasks 9 ‐ 1
Through the use of the SLA modules in CA Unified Infrastructure Management, you can
translate underlying QoS and event metrics into their actual business values for your
organization.
— Describe Service Level Management (SLM), Service Level Agreements (SLA),
Service
Level Objectives (SLO), and QoS
constraints
— Define SLAs, SLOs, and QoS constraints
— By understanding SLM, SLA, and SLO
concepts, you can better translate
underlying QoS metrics to their actual
business value for your organization.
— To configure CA UIM to measure and track SLAs, you need to define SLAs,
SLOs, and QoS constraints using the SLM portlet.
SLM uses a hierarchical set of measurable criteria to monitor and help ensure the validity
of SLAs between customers and service providers. SLM consists of SLAs, SLOs, and QoS
constraints, which will be discussed over the following pages.
A Service Level Agreement is a contract made between a service provider and service
consumer to provide a specific level of service.
For a Service Level Agreement to be enforced, it must be specific.
A general statement such as “the server must be available” is much too broad: ‐ ‐ Does
available mean that the server can be pinged?
‐ Does available mean that a specific service needs to be listening on the interface?
‐ Or, does a Service Level Agreement mean a server must not have over 50% of its
bandwidth used, must not use more than 60% of available memory, and the HTTP page
must respond in 500 ms or less and download at a rate of 100 Kbps?
The SLA manager enables you to define a specific agreement by:
‐ Starting with individual QoS constraints
‐ Consolidating those into a Service Level Objectives
‐ Consolidating SLOs into the final SLA
An SLA will define a service provider’s:
‐ Hours of operation
‐ Maintenance windows
‐ Uptime guarantees
‐ Timeliness in responding to issues
‐ Recovery aspects
‐ Service performance
An SLA consists of one or more SLOs.
SLAs consist of one or more SLOs, which are specific measurable characteristics of the
SLA.
Measureable objectives can include:
— Availability
— Throughput
— Frequency
— Response time
— Bandwidth Utilization
An SLO consists of one or more QoS constraints.
The QoS is the basic element of SLM, which represents the actual value collected and
used centrally to determine the state of the SLO.
As the building blocks for SLOs, the QoS is constrained by the following:
‐ Threshold
‐ Source
‐ Target
‐ Operating period
The SLO definitions require data collected by the monitoring probes. This QoS data is only
collected if the probes are configured to send QoS messages. If you are unable to find the
values you need for an SLA report, you will need to reconfigure the probes to collect the
required metrics.
Here’s a high level look at the SLA flow of information.
CA UIM server comes with two default SLO and three default QoS calculation profiles.
‐ Either type can be modified or have new profiles added.
‐ QoS calculation profiles are modified more often.
‐ Extra types are available in the portlet used to define new profiles.
SLO calculation options include:
‐ AND, OR, and Multi‐Expression
QoS calculation options include:
‐ Average, Interval, Median, and Percentile
Using a multi‐expression method, you can create custom SLO calculation profiles when
needed.
‐ These are configured in the profiles but applied to the SLO.
For setting the expression use the following guidelines; otherwise the expression parser
error will occur.
‐ Use AND, OR, and NOT operators either in upper and lower case.
‐ The QoS values are represented by integer number.
‐ Each expression must be enclosed in bracket.
‐ Each token in the expression must be separated by a space.
The default method is Average. For this calculation, assume there are five samples for the
period and that you set the thresholds to <= 10%.
5+10+12+15+4 = 46; 46/5 = 9.2%
The results do not breach. Therefore this means 100% availability
The Interval method evaluates each sample against the threshold. The number of
samples that pass are divided by the total number of samples to give an availability
percentage.
Again, assume five samples and the threshold at <=10.
5, 10, 12, 15, 4
Three samples pass, therefore availability is 60%.
The Median method first arranges the data into ascending order and then takes the value
in the middle (median). This value is compared to the threshold and an availability
percentage is then computed either as 0% or 100%.
Assume the same data series and a threshold of 10.
5, 10, 12, 15, 4 – 4, 5, 10, 12, 15
The median value is 10 therefore the availability is 100%.
You have a choice of five different calculation methods:
‐ Average
‐ Best
‐ Worst
‐ Weighted
‐ Sequential
The calculation method you choose will determine how the compliance of each SLO
affects the compliance of the overall SLA.
Here’s a reference chart to help you choose the SLA calculation method.
Compliance periods dictate the period of time for which compliance is calculated.
Compliance periods can be:
‐ Daily
‐ Weekly
‐ Monthly
‐ Multiples available are:
‐ Weeks
‐ Months
The SLA engine will apply its predictive analysis over this period.
An SLA consists of one or more SLOs, each with one or more QoS constraints.
– Each QoS constraint calculates the compliance percentage based upon the defined
threshold value.
– The SLO collects compliance data from the QoS constraints and computes the
compliance percentage based on the calculation method selected.
– The SLA process collects the compliance value from the SLOs and calculates the total
compliance value based on the selected calculation method.
For more detailed information and examples, refer to the SLM Portlet in the
Documentation wiki.
The SLM portlet is accessed through the UMP. It is not present in the out‐of‐the box UMP
pages but must be added.
To open the SLM portlet, click Add  Page and click Add  Portlet. The SLM portlet is

only available to CA UIM Server users.
Use the SLM portlet to:
– Create or modify Service Level Agreements
– Create operating and exclusion periods
– Track QoS definitions
– Manage the NIS
Plug‐ins include the following:
– Calculate availability from the median: The median of a number of values is found by
sorting the values in a row in descending order. The value found in the middle of the
row is the median value.
– Calculate availability from number of samples that meet the constraints: This profile
calculates the availability by finding the percentage of samples that meet the
constraints.
– Calculate availability from the average of all samples: This finds the average value of
all samples and compares this value against the defined threshold value.
– Calculate availability from the N'th percentile of all samples: The value for a
percentile you specify is evaluated to determine whether it meets the QoS constraints.
For example, if you specify the 50th percentile, the value that corresponds to the 50th
percentile of the data samples is evaluated. If the value meets the constraints, the
availability is 100 percent. If it does not meet the constraints, the availability is 0
percent.
After you create an SLA, you must create your SLOs, which will calculate data collected
from the QoS constraints.
After you create the SLA in the SLM portlet, you create the SLOs.
If required, you can recalculate an SLA manually.
The SLA context menu provides the option to recalculate an SLA manually.
In the Job Properties dialog, you define the parameters of the SLA recalculation job.
If you are creating an SLA that will have a similar configuration to one that already exists,
you can save time by using the clone operation.
SLA clones are created from existing SLAs.
This screenshot shows the Database Status portlet.
The Database Status portlet is useful for viewing QoS types and the various source/target
combinations collected.
It provides the ability to view, delete, and export data using context menu options.
‐ Use Get Statistics to determine first and last received date/times for QoS points.
‐ Use Delete Data to remove expired data.
‐ Use Merge Objects to merge data with different source and target values.
The Data Management capability enables administrators to delete or invalidate data on
demand.
1. Select the object, source, and target.
2. Choose to delete or invalidate the data
3. Choose to delete historic data if you need to.
4. Select a period for which to perform the maintenance.
Important: Be extremely careful, because once data is deleted, you will be unable to
retrieve it.
‐ Describe Service Level Management (SLM), Service Level Agreements (SLA), Service
Level Objectives (SLO), and QoS constraints
‐ Define SLAs, SLOs, and QoS constraints
‐ Configure Reporting
Module 10: Configure Reporting Capabilities 10 ‐ 1
The UMP of CA UIM has extensive predefined reporting capabilities that enable you to
easily configure the display of business information to meet your business requirements.
This module will take a look at how you can configure reporting capabilities using PRD,
list views, and custom dashboards to help meet the business requirements.
‐ Design charts with the Performance Reports Designer (PRD)
‐ Design reports using the List Designer
‐ Design custom dashboards using the Dashboard Designer
‐ You can configure the display of relevant information using Performance Reports
Designer, List Designer, and the Dashboard Designer.
Performance Reports Designer is intended to be the logical replacement to the
deprecated report_engine functionality in CA UIM Server.
You’ll use the Performance Reports Designer to configure the display of relevant
information.
PRD enables you to create ad‐hoc reports with custom titles, fields, and information that
can then be saved, exported, and used in other UMP views.
Here are the tabs you’ll be using within the Designer tool.
Selection by Host
‐ Select a host and a QoS type and then drag the required targets to the chart.
Selection by Target
‐ Select a QoS type, a target, and then drag required hosts to the chart.
Filters
‐ Create a single or multi‐layer filter and drag the result to the chart.
Let’s take a closer look at Filters.
Filters enable you to create groups of measurement series that can be applied by a
simple drag‐and‐drop method.
‐ Filter groups are dynamic.
‐This means that, if new hosts, devices, and so on are added that fall into this
filter, those hosts are added in future viewings of the report.
‐ If adding a series of charts using the filter selection method, make sure you create
unique filter rules for each chart before dragging.
When creating reports using PRD, keep in mind the following:
‐ Mind your start and end times.
‐ Use a maximum of one day to start or expect delays.
‐ Limit the number of sources or targets to about five.
‐ Use target and source for quick results (ad‐hoc reports)
‐ Use filters to reduce administration and allow for use across multiple customers/origins
‐ Carefully think through your filters.
List views can also have depth added enabling for aggregation of QoS, alarms, and so on,
and drill‐in for in‐depth analysis of performance variations and outliers.
Some examples of good list candidates:
– Groups of servers by origin or source
– Website performance by web servers
– Interface statistics by range or connected host
– Application service or process stats across locations
The List Designer enables you to design lists to be displayed in the List Viewer.
‐ The List Viewer displays information in a table format.
‐ The information can be in the form of text, numbers, gauges, alarms, and spark charts.
Lists are either host‐based or target‐based:
‐ Host‐based lists are typically local polling probes (cdm, processes, and so on).
‐ Target based lists are typically for remote pollers (cisco_monitor, vmware, and so on).
You can create two kinds of lists, detail and groups.
For detail lists, you can click the name of a system to see a drilldown report with data for
the system you clicked. The drilldown report is a Performance Report chart, created in
PRD and specified in the drilldown report setting in the List Designer.
For group lists, you can specify a drilldown template. Typically, the drilldown list contains
data for the individual hosts or targets that make up the group. When viewing the group
list in the List Viewer, you can click the name of a group to display the drilldown
template.
When you create a new list, it is a detail list by default. To create a group list, add groups
to the list.
If you do not have the List Designer permission set in the access control list (ACL), when
you try to run the List Designer, you will see a Permission Denied message.
After your filters are set up and working, you can populate the lists with data by adding
columns containing one of the following data visualizations:
‐ Numeric
‐ Spark
‐ Gauge
‐ Alarm
‐ Status
‐ Info
‐ Timeslice
The available data visualizations are viewed as:
‐ Numeric
‐ Spark ‐ line
‐ Spark ‐ column
‐ Gauge
‐ Alarm
‐ Status
‐ Info
‐ Source
‐ Origin
After you configure data in a column, you should save your progress.
The directory tree enables you to select a directory to save the list in
The Delete button enables you to delete the list that is selected in the directory tree.
From the pull‐down menu, you can choose the following types of access from the list:
– Public: Can be viewed by all users
– Account: Can be viewed only by users of the account you are logged in as
Note: Saving to an account requires the Portal Administrator ACL.
– Private: Can be viewed only by you
When saving over an OOTB list, the list will be overwritten at next wasp restart.
To view a list, you add the List Viewer application to a page.
‐ In the List Viewer portlet, use Open to browse the existing views to which you have
access.
‐ Set a default list through the portlet Preferences.
‐ You can also export List View snapshots as PDFs.
You can click certain cells in the List Viewer to drill down and see more information.
Drilling down will show graphically the list views in a PRD chart.
The information displayed depends on the type of cell you click in.
To add a drilldown, create a new PRD report or use an existing report, and tie the
drilldown report by clicking the Find icon and selecting your required report.
When building a multi‐layer list, plan the layout of the structure in your head or on paper.
For example, if you need to show performance for the your main websites across
multiple different locations, plan to create children subgroups that contain all the URL
performance metrics across each different location and roll it up into a Per Location view.
Or, if you need monitor website performance, plan to drill into subgroups that contain
location‐based information per website and roll that up into a Per Website view.
Whatever the case, plan the metrics and alarms you need to display at the top level
earlier rather than later.
When you have multiple groups defined within your list report, the drilldown report
functionality now points at List View Reports and not PRDs.
You can configure the display of relevant information using the Dashboard Designer.
Dashboards display data in graphic elements, such as gauges, charts, tables, images, or
shapes.
These elements are referred to as widgets and can display data from several types of data
sources, and can be customized with a wide range of colors, fonts, and sounds.
When you save and publish a dashboard, it will be available in the UMP, where you can
see the state and QoS values of the monitored systems and also manage the alarms.
In order for widgets to display data, they must be assigned one of the defined data
sources.
If you have configured an object and want to save and use it in the future when designing
other dashboards, you would right‐click the object and click Save as Template.
The data source definition includes filters that determine what data is displayed by a
widget.
The Test Filter button results list provides the means to verify the filter definition.
(Optional)
Watch the CA UIM Dashboards videos for a closer look at how to use the Dashboard
Designer to create custom dashboards prior to the next lab exercise.
‐ Design charts with the Performance Reports Designer (PRD)
‐ Design reports using the List Designer
‐ Design custom dashboards using the Dashboard Designer
‐ Perform Advanced Probe Configuration
Module 11: UMP and Portal Views 11 ‐ 1
By configuring UMP, you can customize the information presented to any individual or
group according to their business needs, based on their role or organization.
‐ Differentiate between users, accounts, and account contacts
‐ Create a site
‐ Build a portal view
‐ By understanding the difference between users, accounts, and contacts, you can
manage them appropriately.
‐ By configuring communities and portal views, you can present users and account
contacts with information appropriate to their role or organization.
By understanding the difference between users, accounts and contacts, you can manage
them appropriately.
The different types of users available in the Infrastructure Manager include:
– CA UIM users
• CA UIM users are created and managed using the Infrastructure Manager.
– LDAP users
• LDAP users are users that authenticate through the LDAP protocol, but can be
managed with CA UIM.
– Account contacts
• Account contacts are users that are added to accounts created in CA UIM. The
Account contacts are the only users that cannot log in to the Infrastructure Manager.
The access control list (ACL) is a list of permissions applied to an object on the network.
These permissions explicitly define the level of access a user has to that object.
The different levels of access include:
– Read
• Read allows a user to view an object but not modify it.
– Write
• Write allows a user to view an object and modify it.
– Admin
• Admin allows a user administrative rights on the object.
– Super
• Super gives the user full access to the object.
Accounts are created to group users, thus providing ease of administration and
management.
Accounts in CA UIM are containers, associated with one or more origins.
‐ Users, also called account contacts, are logins that are added to accounts.
‐ Users will also have an associated ACL before being added to an account.
Now that you have examined the differences between and created users, accounts, and
contacts, you will create a site to present the information that is appropriate to their
specific role or organization.
Sites are a convenient and scalable way to assign pages to multiple users and groups of
users.
‐ Sites provide the ability to assign portal views (.lar files, pages/portlets) to individuals
based on membership of that site.
‐ Sites are dynamic in that when a change is made to a page, the effect is viewable
immediately by members of that site.
‐ Sites to which a user belongs appear on the Go to menu.
Creating a site is one way to present users and contacts with information appropriate to
their role or organization. Another way is to build a page view.
You can start to build a page view by clicking Add  Page and then add portlets to it.
Pages are web pages that have been created in UMP.
By default, UMP provides five pages:
– Home
– Unified Dashboards
– Reports
– Design
– Configuration
Depending on your role, you can edit these pages, add new pages, or change the look
and feel of a page.
For example, this screenshot shows a new collaboration page with a variety of blog, wiki,
and message board portlets.
PRD enables you to create reports with custom titles, fields, and information that can
then be saved, exported, or used in other portal views. You can:
– Quickly design reports using drag and drop to analyze data in minutes and reduce
deployment.
– Use elastic charts, which virtually eliminate future administration by using filters to

dynamically add or remove data series based on user‐defined rules.
– Cross‐analyze performance metrics across multiple data center resources faster to
quickly analyze data, and isolate the root cause for any time period
– Combine the best of real‐time and historical data in a single report
– Take advantage of powerful knowledge transfer through the CA UIM user community
by importing and exporting reports to share within the community.
‐ Differentiate between users, accounts, and account contacts
‐ Create a site
‐ Build a portal view
‐ Perform advanced probe configurations and troubleshooting
Module 12: Advanced Probe Configuration and Troubleshooting 12 ‐ 1
CA UIM includes a variety of probe configurations that enable you to perform advanced
monitoring activities, such as monitoring SNMP‐enabled hardware or software and
processing syslog messages. Knowing the answers to various problems you might
encounter with CA UIM will help you resolve these issues quickly and shorten the time to
market for an organization.
‐ Perform advanced probe configurations
‐ Troubleshoot CA UIM
‐ You can apply some commonly used advanced probe configurations to
perform a variety of monitoring functions.
‐ By using CA UIM utilities, you can troubleshoot issues related to the CA UIM
infrastructure.
You can apply some commonly used advanced probe configurations to perform a variety
of monitoring functions.
Examples of probes and their monitoring‐related functions include the following:
‐ The snmptoolkit probe enables you to monitor SNMPv1, SNMPv2c, and SNMPv3
devices.
‐ The sysloggtw probe acts as a gateway from the syslog format into CA UIM.
‐ The ha probe enables you to enable/disable queues, probes, and the nas in a high‐
availability (HA) configuration.
The snmptoolkit probe is a monitoring probe for rapidly creating comprehensive SNMP‐
based static and dynamic monitoring configurations for devices with SNMP support,
including SNMP tables.
The probe performs SNMP GET queries for SNMP tables along with both static and
dynamic Object Identifiers (OIDs) to selected SNMP devices, transforming the query
results into alarms and/or Quality of Service metrics for performance, availability, and
SLA monitoring.
Syslog is a standard for logging computer data.
CA UIM uses the sysloggtw probe, which acts as a link to syslog. A syslog probe is used to
log any messages generated by events on the system and forward them to designated
administrators for analysis and troubleshooting if required.
– Most network devices, such as routers, switches, bridges, and so on, report events
using SNMP and the well‐known syslog format.
– Any incoming syslog messages are configured to produce any of the following three
results:
• Generate an alarm
• Generate SYSLOG‐IN messages
• Log the message to a file
To receive syslog messages, configure the hub probe with the required queue.
The logmon probe can help systems operation staff by:
– Generating an alarm when log entries identify conditions that warrant this
– Filtering out the log entries that need manual action
– Specifying a more informative text in the alarm message
When a hub goes down, robots fail over automatically, but consider what happens to the
following:
‐ Messages
Alarms
QoS
‐ SLM components
‐ Off‐board monitoring on the hub
net_connect
interface_traffic
And so on
‐ Automated notifications
AO profiles such as email and SMS
The ha probe maintains failover of your CA UIM system by using a secondary hub to
monitor the primary hub.
If the ha probe loses contact with the primary hub, it initiates a failover after a defined
interval.
When the primary hub comes back online, the ha probe reverses the failover, initiating
failback after a defined interval.
The ha probe must be installed on the computer hosting the secondary hub.
Configure NAS forwarding and replication from the Setup tab.
To create a new destination or edit or delete an existing destination:
‐ Right‐click a blank area and click New, Edit, or Delete.
You are presented with a list of all the alarm servers in your domain.
You can then select which options to use.
The As event responder option will be added automatically when needed.
You can also forward scripts and the NAS configuration:
‐Select the required option(s) in the lower Section
of the NAS Replication/Forwarding dialog.
‐ Select the appropriate Max Transfer Blocksize and
Timeout values on the Advanced tab.
When the primary hub goes down, the ha probe will:
– Start/stop queues
• Stop forwarding queues from the secondary hub to the primary hub
• Start attach queues for local probes
– Start/stop probes for:
• NAS
• SLM components
• Central off‐board monitoring
– Start/stop AO profiles
In day‐to‐day maintenance of a system with this level of complexity, it is essential that
you are able to troubleshoot any issues that might arise from configuration tasks or from
any network changes. Knowing where to look is the first step in ascertaining what is
contributing to an issue. Understanding the system will help you determine the
appropriate steps for resolution.
Each probe has a log file that contains information on the probe that you can use for
debugging purposes.
You can access the log files from the Infrastructure Manager.
‐Set the level of detail displayed in the Log Viewer by configuring the probe.
Use DrNimbus to analyze specific message contents or to help diagnose problems at the
message level:
‐ Queue Viewer
‐ Message Sniffer
You should merge QoS data to eliminate separate sets of QoS data for the same device,
so that it can be reported on collectively. There are a number of different reasons that
you might have to merge QoS data.
With our example from a previous module, you could have two different sets of QoS data
that point to one target, and you need to merge this data together.
After a profile is renamed, use the Database Status Portal to merge data associated with
the profile name to data associated with the new profile name.
Renaming a robot could be another example. For instance, one set of data is associated
with one robot name, with another associated with a different or new robot name, so
you would merge the data, using the same process. Good planning prior to
implementation will reduce the need to rename a robot, as there are some potential
consequences effecting , not only the QoS database, but alarm filtering as well.
It is strongly recommended that you contact CA Support prior to making a robot name
change.
‐ Perform advanced probe configurations
‐ Troubleshoot CA UIM
‐ Merge QoS data
You are now able to do the following:
‐ Plan a scalable management of the IT infrastructure of your business.
‐ Gain insights about monitored data and customize information appropriate to your role
or business context using the UMP.
‐ Set up the basic parameters of the NAS quickly to view and manage alarms.
‐ Extend the monitoring capabilities of CA UIM through the configuration of probes.
‐ Leverage probe package functionality to preconfigure monitored metrics sets and
deploy these standardized sets rapidly and effectively to the managed infrastructure
You are now able to do the following:
‐ Scale the CA UIM architecture to meet your business needs by deploying multiple hubs.
‐ Apply the advanced capabilities of the NAS AO to perform complex alarm handling,
thereby reducing or eliminating manual intervention.
‐ Translate underlying QoS metrics into their actual business values for your organization.
Congratulations, you have completed this course. You will receive an email with a link to
a survey requesting your feedback on this learning experience.
Please take a few moments to complete the survey.

CA Unified Infrastructure Management 8.4: System Administration Foundations 200

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CA Unified Infrastructure Management 8.4: System Administration Foundations 200

Загружено:

Авторское право:

Доступные форматы

CA Unified Infrastructure

20NMS20200SG1 © 2014 CA. ALL RIGHTS RESERVED.

The manufacturer of these Materials is CA.

1. CA UIM Architecture and Monitoring Governance

2. Create USM Groups

3. Discovery & Robot Deployment

4. Examine Monitored Data

© 2016 CA. All rights reserved.

5. Basic Alarm Notifications

6. Advanced Monitoring Administration

7. Perform Advanced Robot Configurations

8. Advanced Alarm Configuration

9. Perform SLM Tasks

© 2016 CA. All rights reserved.

11. UMP and Portal Views

12. Advanced Probe Configuration and Troubleshooting

© 2016 CA. All rights reserved.

The qos_processor subscribes to the qos messages on the message bus to store QoS

For the net_connect probe, the script uses the first three characters from the qos target

‐ If a match is found, it checks to see if the qos metric is from the cdm or rsp probe.

To open the SLM portlet, click Add  Page and click Add  Portlet. The SLM portlet is

– Use elastic charts, which virtually eliminate future administration by using filters to

Вам также может понравиться