Upload
ca-technologies
View
482
Download
2
Embed Size (px)
Citation preview
Pre-Con Education: CA Service Operations Insight Power User Crash CourseJeff Morris, Ahmed Kira & Kirk O’QuinnCA Technologies
Session Number OCX47E #CAWorld
OpsCenter
2 © 2014 CA. ALL RIGHTS RESERVED.
Panel Session
Kirk O’Quinn
CA Technologies
Solutions Architect
Jeff Morris
CA Technologies
Principal Engineering Services Architect
Ahmed Kira
CA Technologies
Advisor, Presales
3 © 2014 CA. ALL RIGHTS RESERVED.
Abstract
This 3 hour hands-on session will cover the key aspects of how CA Service Operations Insight can integrate and correlate information from your many domain management tools into cohesive service models, monitor and manage your operations at the service level, and transform your NOC into a 21st century Business Operations Center. Topics covered in this session include:
– Product Architecture and Overview
– Centralized Event Management
– UIM (Nimsoft) Integration
– Event Enrichment
– Cross-Domain Correlation
– Integrating SNMP data sources
– Notifications and Escalations
– Managing to the Service
– Service Modeling / Alert Propagation
– Advanced Topics / Troubleshooting
Jeff Morris
CA Technologies
Principal Engineering Services Architect
4 © 2014 CA. ALL RIGHTS RESERVED.
Quick Show of Hands
Hands up if your organization owns CA SOI and has it deployed / plans to deploy in the near future?
5 © 2014 CA. ALL RIGHTS RESERVED.
Agenda
SOI OVERVIEW
SOI ARCHITECTURE & CORE CONCEPTS
TROUBLESHOOTING
CENTRALIZED EVENT MANAGEMENT (+LAB)
MANAGING TO SERVICE (+ LAB)
ADVANCED TOPICS
1
2
3
4
5
6
SOI Overview
7 © 2014 CA. ALL RIGHTS RESERVED.
The Problem: Too many tools, Services Cross Too Many Silos
Silo Domain Managers do not provide a service-wide perspective
Service #1
Service #2
Service #3
Service #4
Service #5
Service #6
Client Systems
Applications
Databases
Servers
Storage
Networks
Silos
8 © 2014 CA. ALL RIGHTS RESERVED.
IT Operations without Service Operations ManagementThe “Blame Avoidance” Game
10 © 2014 CA. ALL RIGHTS RESERVED.
Service Operations Management Designed for the Today’s Dynamic Business and IT Environment
Service operations management
Comprehensive domain management Service-aware domain discovery, root
cause analysis, performance management, triage and remediation
Unified event management Query, normalize, correlate cross-domain
events Manage and escalate alerts by policies
Dynamic business service modeling Real time cross-domain service discovery,
modeling and maintenance
Automated actions Initiates automated escalation,
synchronization and workflow based on service impact and risk
Integrated service level performance management
Service performance and comparison management
Contractual service level management
Service analytics and alerts Analytics and alerting for service quality,
availability, impact and risk
11 © 2014 CA. ALL RIGHTS RESERVED.
Repeatable
Defined
Managed
OptimizedA five-phase approach
11
SOI: It is all about achieving IT maturity
Service-oriented → Lean →Event-oriented →
Initial
Silo-oriented → Business-oriented →
Ph
ase
Att
rib
ute
s
Individual capabilities, not processes
1
4
3
5
2
CA Service Operations Insight
12 © 2014 CA. ALL RIGHTS RESERVED.
Step 1: Consolidated Alarm Management in SOI
Alert
Queue
List
Alarms
13 © 2014 CA. ALL RIGHTS RESERVED.
Step 2: Service Modeling
UCS Blade & Chassis
Virtual Machines
Networking
Business Transactions
ApplicationComponents
ESX Host
Ant TrailIndicating
Root Cause Location
14 © 2014 CA. ALL RIGHTS RESERVED.
Business
services listed
according to:
Business
importance
Quality level
Risk to quality
Business and IT
subservices
Real-time
service
status
indicators
Historical
service
status
details
Step 3: Service Visualization for all Stakeholders
SLA Health
Quality Risk
Availability
14
SOI Architecture and Core Concepts
17 © 2014 CA. ALL RIGHTS RESERVED.
SOI Core Concepts
2 Configuration Item
3 Infrastructure Alert
4 Service
5 Service Alert
To plan a successful installation, you need to understand the terms and concepts used in CA SOI.
1 Catalyst / USM
18 © 2014 CA. ALL RIGHTS RESERVED.
SOI Architecture
19 © 2014 CA. ALL RIGHTS RESERVED.19
CA Catalyst: Vendor Agnostic IntegrationMultiple CA and 3rd Party Integrations available today or in development
CA Catalyst
21 © 2014 CA. ALL RIGHTS RESERVED.
Unified Connector Framework
Unified Connector Framework
ProductAdaptor
CIs, Events, ServicesActions on Silo
MDR
CA Catalyst Bus
EI
USMEI provides policy based data transformation and normalization services for the UCF
The Unified Connector Framework (UCF) exposes standarized interfaces for building high quality, consistent integrations, whether CA or 3rd party
UCF, Product Adaptor and EI Policy = Catalyst Connector
22 © 2014 CA. ALL RIGHTS RESERVED.22 © Computer Associates 2010
Catalyst integration platform
MDR1
MDR2
MDR3
23 © 2014 CA. ALL RIGHTS RESERVED.
A configuration item (CI) is a representation of an IT element managed by a domain manager converted to USM format.
Configuration Item
Element Managed by Domain Manager (CA Spectrum)
Corresponding CIin CA SOI
24 © 2014 CA. ALL RIGHTS RESERVED.
Correlation Definition
Correlation identifies related CIs managed across multiple domains. Correlation happens automatically in CA SOI. No additional OOTB configuration is required.
Each domain ‘projection’ of the CI is added to a single ‘USM Notebook’
In this example, APM, eHealth and Spectrum are all projecting what they know about the system ‘TIXCHANGE-3.ca.com’ into USM, and those projections have been automatically correlated together into a single logical representation
25 © 2014 CA. ALL RIGHTS RESERVED.
Reconciliation Definition
Reconciliation determines which pieces of domain data are the most reliable, and assigns them to the logical ‘reconciled’ (merged) representation of the CI
26 © 2014 CA. ALL RIGHTS RESERVED.
An infrastructure alert is a fault condition detected by a domain manager – these are automatically forwarded to SOI by the connectors.
Within SOI, alerts are automatically associated with the corresponding CI, and will be mapped to an SOI Severity.
Infrastructure Alert
27 © 2014 CA. ALL RIGHTS RESERVED.
Service
The concept of a service model, or service, is central to CA SOI (We’ll be exploring them in much more detail later)
28 © 2014 CA. ALL RIGHTS RESERVED.
CA SOI generates service alerts based on the impact of related infrastructure alerts.
Service alerts have a corresponding Root Cause alert to quickly identify the highest impacting infrastructure condition affecting the service
Service Alert
Centralized Event Management
30 © 2014 CA. ALL RIGHTS RESERVED.
ServiceImpacting
Alerts
Alerts
Events
Red
uce Q
uan
tity
, In
crease Q
uali
ty
The Event Management Pyramid
Root Causes
31 © 2014 CA. ALL RIGHTS RESERVED.
Unified Alert Management Architecture
Non-Service Impacting Alerts
32 © 2014 CA. ALL RIGHTS RESERVED.
Leverages existing Catalyst Connectors as ‘Event Collectors’– Connectors modified to store historical events and expose interfaces
to enable federated queries and remote configuration of policies
Unified Event and Alert Management Architecture
Defining an Alert Queue
34 © 2014 CA. ALL RIGHTS RESERVED.
What is an Alert Queue?
Filtering Mechanism for Alerts within the SOI Console
Traditional Event Management Concept
Allows different teams to be focused on alerts for CIs which they are responsible– (i.e. Windows, Linux server teams)
35 © 2014 CA. ALL RIGHTS RESERVED.
Alert Queues Tab Operations
Use the toolbar or the right-click context menu to:
Define a new queue
Edit an existing queue
Delete an existing queue
36 © 2014 CA. ALL RIGHTS RESERVED.
Define an Alert Queue
37 © 2014 CA. ALL RIGHTS RESERVED.
Assign Escalation Policy to Alert Queue
38 © 2014 CA. ALL RIGHTS RESERVED.
Assign User Groups to Alert Queues
39 © 2014 CA. ALL RIGHTS RESERVED.
Confirm and Save the Queue
40 © 2014 CA. ALL RIGHTS RESERVED.
Confirm New Queue Exists
41 © 2014 CA. ALL RIGHTS RESERVED.
Control Alert Queue Access
Two methods are available for defining Alert Queue access:
Using the Alert Queue wizard when defining a new queue and when editing an existing queueOn the Users tab, select a User
Group and add queue access using the Alert Queues Access tab
The Alert Queues Access tab provides similar functionality as the Service Access tab
Creating Escalation Policies and Actions
43 © 2014 CA. ALL RIGHTS RESERVED.
Escalation Policies and Actions
Escalation Policy– Filter or criteria for related alerts
– Alert queue can be defined as the filter
– Additional Time criteria for when to take action
Escalation Actions– Action to be taken on all alerts matching
– E-mail, create SD Ticket, run custom script, Clear Alert, etc.
44 © 2014 CA. ALL RIGHTS RESERVED.
Escalation ManagementEscalation Policies Policy can be triggered based on any property of the alarm including the user defined
properties that can be set through enrichment
You can define escalation policy to include or exclude alarms for escalation based on:– Class or Instance of impacted CI
– Symptoms or root cause conditions
– Alarm severity or service impact
– Alarms impacting CIs or services in Maintenance
– Alarms that have not been acknowledged, assigned or ticketed within a given timeframe, or simply based on the age of the alarm itself
Policy can take account of service business hours and can be assigned a schedule (calendar) to determine whether it should be applied
45 © 2014 CA. ALL RIGHTS RESERVED.
Escalation ManagementEscalation Actions Once an alarm has been identified as a candidate for escalation, you can then
assign appropriate actions to take, including:– Sending an email
– Raising a trouble ticket
– Executing a command
When invoking an action you can substitute in elements of the alarm or the impacted CIs and Service as parameters
The results of any action are stored in the alarm as an annotation so you have the full audit trail associated with the alarm and any attempts to diagnose or remediate the condition
SD tickets and alarms are synchronized so if either is assigned, or closed, that can be reflected back to the other
46 © 2014 CA. ALL RIGHTS RESERVED.
Define an Escalation Policy
Specifying automatic actions to occur in response to variousconditions helps ensure the policies are escalated
in a timely and effective manner.
47 © 2014 CA. ALL RIGHTS RESERVED.
An escalation policy can be global or service specific.
Policy Types
48 © 2014 CA. ALL RIGHTS RESERVED.
Global escalation policies are applied to services on an all or none basis.
Service specific escalation policies are selectively applied to services.
Policy Types Continued
49 © 2014 CA. ALL RIGHTS RESERVED.
Policy Criteria
Escalation policies can be based on different criteria.
Act on alerts based on attribute value
Act on alerts based on alert type
Act on alerts based on time threshold
50 © 2014 CA. ALL RIGHTS RESERVED.
Schedule
The escalation schedule identifies when the policy is active.
51 © 2014 CA. ALL RIGHTS RESERVED.
One or more actions can be performed when an escalation policy is triggered.
Policy Actions
52 © 2014 CA. ALL RIGHTS RESERVED.
E-mails can be customized and tailored using data from the alert triggering the action
E-Mail Actions
53 © 2014 CA. ALL RIGHTS RESERVED.
Schedule Maintenance
Services and CIs require regular maintenance.
Maintenance schedules identify regular maintenance time periods.
Specifying how maintenance mode affects the impact of CIs and services enables you to define an effective escalation policy.
54 © 2014 CA. ALL RIGHTS RESERVED.
The Operational Mode indicates the current maintenance status.
Production
Maintenance
Operational Mode
Maintenance Mode Icon
55 © 2014 CA. ALL RIGHTS RESERVED.
Maintenance Mode Impact Propagation
Global settings control impact propagation for CIs in maintenance mode.
Propagate Maintenance Impact = Yes
Propagate Maintenance Impact = No
56 © 2014 CA. ALL RIGHTS RESERVED.
Maintenance Mode Alert Escalation
Alert escalation behavior for CIs and services in maintenance mode is specific to each escalation policy.
57 © 2014 CA. ALL RIGHTS RESERVED.
Define Maintenance Schedules
The Maintenance Schedules subview provides the means to create new schedules.
Event Policy – Filtering / Enrichment
59 © 2014 CA. ALL RIGHTS RESERVED.
Event Streams Can Be Overwhelming
Managing events is like managing a fire hose…
Too much volume
Impurities
Inconsistent composition
60 © 2014 CA. ALL RIGHTS RESERVED.
Event Filtering and Normalization is Key to Success
Ultimately, the Alert Console should contain:
Minimum volume
Maximum quality (articulation of problem)
Consistent composition (same schema)
SOI Alert Console
61 © 2014 CA. ALL RIGHTS RESERVED.
Open the Event Policy DialogDefine Event Search Criteria
62 © 2014 CA. ALL RIGHTS RESERVED.
Specify Simple Event PatternsDefine Event Search Criteria
When searching for multiple events using the Any criterion, the search is satisfied if an event occurs that meets any of the specified search patterns.
63 © 2014 CA. ALL RIGHTS RESERVED.
Open Create Event Policy DialogDefine Enrich Event Policy
Click the Create Policy button
64 © 2014 CA. ALL RIGHTS RESERVED.
Define Event Policy
Cross-Domain Event Correlation
Define SOI Alert Queues based on Spectrum Global Collections or Custom Attributes
67 © 2014 CA. ALL RIGHTS RESERVED.
Interface to Map Additional Attributes from CA Spectrum to CA SOI
New Configuration file AdditionalAtrributes.xml
Following format used to add the additional model attributes
<Models>
<Attribute id="attribute id" name="attribute name"/>
</Models>
Example:
<Models>
<Attribute id="0x23000d" name="Location"/>
<Attribute id="0x23000c" name="ContactPerson"/>
<Attribute id="0x12adb" name="CollectionsModelNameString"/>
</Models>
Connector needs to be restarted to apply the changes
68 © 2014 CA. ALL RIGHTS RESERVED.
Interface to Map Additional Attributes from CA Spectrum to CA SOI
Map the new attributes in CA Spectrum policy file to transfer these attributes to Catalyst
<Field output=“CIUserAttribute1" format="{0}" input=" Location "/>
You can also map to user-defined USM property, in case relevant target property is not found
69 © 2014 CA. ALL RIGHTS RESERVED.
CA SOI UI Showing Additional Attributes
Showing Location, ContactPerson and CollectionsModelNameString in user attributes
70 © 2014 CA. ALL RIGHTS RESERVED.
Creating a new alert queue based on new attribute
Creating Alert queue to show alerts on CIs belonging to global collection ‘uiop’
Event Management Lab (20 minutes)
72 © 2014 CA. ALL RIGHTS RESERVED.
Event Management Lab
Experiment with Alert Queues
Create an Escalation Policy / Action for your Alert Queue to send yourself an e-mail notification
(Optional) Experiment with Event Policy– Filter or Enrich an incoming event
– Should impact your Alert Queue
Break (10 minutes)
Service Modeling Principles
75 © 2014 CA. ALL RIGHTS RESERVED.
What is a Service?
Different meanings to different people– Often considered somewhat synonymous with application
Business Service– A suite of application components and associated infrastructure working together to provide a
specific named value to the organization and/or its customers
– i.e. “On-Line Bill Pay“
IT Service – Somewhat more low-level – may not have a front end
– Components of many business services
– i.e. “VOIP"
75
76 © 2014 CA. ALL RIGHTS RESERVED.
Service Topology
Service propagation based on:
- Alarm Severity
- CI Significance
- Relationship type
• Letter (O) depicts relationship type
• Number (8) depicts significance of child CI on scale of 1-10
77 © 2014 CA. ALL RIGHTS RESERVED.
CI Severity
Severity indicates the condition of a CI.Severity Color Description
Normal (0) Green Operational
Minor (1) Yellow A nominal displacement of CI function that may or may not merit inspection
Major (2) Orange A serious causal change typically leading to degradation of function
Critical (3) Red High probability of imminent failure and severe degradation of service
Down (4) Burgundy The CI is incapable of providing function or service
78 © 2014 CA. ALL RIGHTS RESERVED.
CI Severity Continued
Severity values do not propagate from child to parent.– The impact of CI severity is propagated.
– The impact is derived from the fault condition asserted on a CI and the significance value assigned to that CI.
Parent
Children
Severity values are assigned to CIs with directly associated alerts
79 © 2014 CA. ALL RIGHTS RESERVED.
Significance
A value that states how important a CI is to a related item
80 © 2014 CA. ALL RIGHTS RESERVED.
Significance Continued
Default significance values are established for each CI class type.
81 © 2014 CA. ALL RIGHTS RESERVED.
Impact
Identifies what CI fault conditions really mean to the service that the CIs support
Impact Color Description
0 Green Operational
1 – 10 Yellow Slightly degraded
11 – 20 Orange Moderately degraded
21 – 30 Red Severely degraded
31 – 40 Burgundy Down
Severity
Normal (0)
Minor (1)
Major (2)
Critical (3)
Down (4)
Impact
0
1 – 10
11 – 20
21 – 30
31 – 40
x =
82 © 2014 CA. ALL RIGHTS RESERVED.
Impact Continued
Impact values are propagated.
Impact is propagated to related CIs.
83 © 2014 CA. ALL RIGHTS RESERVED.
Groups
Groups are intermediate objects that relate CIs to one another by some role or function.
Group
84 © 2014 CA. ALL RIGHTS RESERVED.
Propagation Types
Propagation Types determine how impact values are propagated.– Aggregate
– Bound
– Custom
– Operative
85 © 2014 CA. ALL RIGHTS RESERVED.
Aggregate Propagation
Aggregate propagation indicates a general-purpose relationship that propagates impact from one CI to another.
86 © 2014 CA. ALL RIGHTS RESERVED.
Bound Propagation
Bound propagation indicates a bidirectional relationship between two CIs.
87 © 2014 CA. ALL RIGHTS RESERVED.
Custom Propagation
Custom propagation indicates that one CI may depend on several other CIs for some behavior or function.
88 © 2014 CA. ALL RIGHTS RESERVED.
Operative Propagation
Operative propagation indicates a related item is affected only if the impact value of a CI exceeds a defined threshold.
89 © 2014 CA. ALL RIGHTS RESERVED.
Relationship Types
Relationships refine how impact values are propagated.
90 © 2014 CA. ALL RIGHTS RESERVED.
Custom Propagation Policy
Custom policy further refines how impact is propagated for the IsAffectedBy and IsEvolutionOf relationship types.
91 © 2014 CA. ALL RIGHTS RESERVED.
Normal GranularityService Granularity
Normal granularity
Direct alerts from low level CIs explicitly included in the Service model are assigned to the low level child object
• Direct alerts are alerts that are instantiated directly against the object
• Low level CIs belong to classes that fall beneath the Top Level classes
92 © 2014 CA. ALL RIGHTS RESERVED.
Service Granularity
Low granularity (LoFi)– Direct alerts are assigned to low level child objects
The assigned low level child alerts behave as standard managed alerts
– Alerts from low level child CIs not included in the Service model are intercepted and propagated to the parent CI
– The association is established by matching the device ID
– The Low Fidelity Impact icon denotes the presence of a low granularity alert
Low Fidelity Impact icon
93 © 2014 CA. ALL RIGHTS RESERVED.
Service Granularity
Low Granularity Example
Direct alert
LoFi alert
Importing a Service
95 © 2014 CA. ALL RIGHTS RESERVED.
Import Services
Domain managers such asCA Spectrum Infrastructure Manager, CA APM, and CA CMDB have service concept.
Previously defined services in domainmanagers can be imported intoCA SOI.– This leverages your existing investment.
– This establishes that CA SOI should manage the service.
– The imported services can be modified and extended.
96 © 2014 CA. ALL RIGHTS RESERVED.
Auto Import Services
When Auto import is set to Yes for a connector:
– All existing domain manager services are immediately imported.
– Any new domain manager services are also imported after they become known to the connector.
Some connectors are not Auto import capable.
The Auto import toggle buttons are located here.
97 © 2014 CA. ALL RIGHTS RESERVED.
Manual Service Import
Accomplished using the Import Services dialog.
Service Discovery Policies
99 © 2014 CA. ALL RIGHTS RESERVED.
Working with Service Discovery
Service Discovery allows you to define policies that will automatically build and maintain services in real time
1 Understanding SD Policy Types
2 Navigating the SD Policy Editor
100 © 2014 CA. ALL RIGHTS RESERVED.
SD Policies
Three types of policies are supported:– Dynamic Services
Define policies to place relevant CIs (system-wide) in a service
– Automatic Relationships
Define policies to connect matching CIs (system-wide)
– Unmanaged Relationships
Define policies that establishes managed relationships from existing unmanaged relationships
101 © 2014 CA. ALL RIGHTS RESERVED.
Navigate the SD Policy Editor
SD policies are defined in the Policy Editor.
102 © 2014 CA. ALL RIGHTS RESERVED.
SD Policy Editor UI
Access from the SOI Console
To access the SD Policy Editor,
click Tools > Service Discovery Policies.
At startup, with the root node selected,
the right pane displays SD policy
descriptor revision details.
103 © 2014 CA. ALL RIGHTS RESERVED.
SD Policy Editor UI
During Operation, when a policy group is selected in the left pane, the right pane displays the list of policies that fall beneath the selection.
104 © 2014 CA. ALL RIGHTS RESERVED.
SD Policy Wizards
Context sensitive menus provides access to SD policy wizards.– The menus are triggered from the navigation tree node.
– The Create, Add, and Modify actions launch the respective policy editor wizard.
105 © 2014 CA. ALL RIGHTS RESERVED.
Define Dynamic Service Policy
1 Define Service
2 Confirm
3 Confirm Step Validation
SD policies determine what services are
automatically created and maintained.
106 © 2014 CA. ALL RIGHTS RESERVED.
Step 1: Define Service
Panel space is reserved for messages
Required input fields are marked with an asterisk (*)
107 © 2014 CA. ALL RIGHTS RESERVED.
Step 2: Confirm
108 © 2014 CA. ALL RIGHTS RESERVED.
Step 3: Confirm Step Validation
Warning messages identify when the validation process identifies
problematic service definition policies.
109 © 2014 CA. ALL RIGHTS RESERVED.
Define Automatic Relationship Policy
1 Source Criteria
2 Target Criteria
3 Match Criteria
SD policies determine what relationships areautomatically created and maintained.
4 Relationship Scope
5 Confirm
110 © 2014 CA. ALL RIGHTS RESERVED.
Step 1: Source Criteria
Panel space is reserved for messages
Required input fields are marked with an asterisk (*)
111 © 2014 CA. ALL RIGHTS RESERVED.
Step 2: Target Criteria
112 © 2014 CA. ALL RIGHTS RESERVED.
Step 3: Match Criteria
113 © 2014 CA. ALL RIGHTS RESERVED.
Step 4: Relationship Scope
All Services or Specific Services
114 © 2014 CA. ALL RIGHTS RESERVED.
Step 4: Relationship Scope
SD Engine Relationship Scope Processing1. Identify CI pairs fitting the SOURCE, TARGET, and MATCH criteria
2. For each CI pair, identify Services containing the SOURCE CI that fit the Relationship Scope specification
1. Add the SOURCE->TARGET relationship defined by the policy to each Service within the identified set
115 © 2014 CA. ALL RIGHTS RESERVED.
Step 5: Confirm
116 © 2014 CA. ALL RIGHTS RESERVED.
Define Unmanaged Relationships
Domain manager knowledge of unmanaged relationshipscan be easily used to extend the managed relationship
hierarchy within CA SOI services
1 Default Behavior
3 Define Unmanaged Relationship Policy
2 Unmanaged Relationship Discovery
117 © 2014 CA. ALL RIGHTS RESERVED.
ServiceComputer
SystemPort
Published by the connector
Created in CA SOI
Unmanaged Relationship• Invisible in CA SOI Service Topology
Managed Relationship• Scoped to the Service
Default Behavior
Relationships published by connectors are unmanaged– MDRs are not aware of the services in which CIs are used and so are
unable to scope the relationships to CA SOI services.
– The unmanaged relationships are not part of nor visible in the CA SOI service topology.
– Alert impact from unmanaged CIs is not propagated to the service.
118 © 2014 CA. ALL RIGHTS RESERVED.
ServiceComputer
System
Unmanaged Relationship Discovery
Establishes managed relationships from unmanaged relationships– Looks for unmanaged relationships whose source CI is in a Service
– Creates a managed copy of the relationship scoped to the same service as the source CI
Implemented as a new Service Discovery policy type
Port
Published by the connectorCreated in
CA SOI
Managed Relationship• Starts in a managed CI• Scoped to the service• Created by the policy
119 © 2014 CA. ALL RIGHTS RESERVED.
Step 1: Relationship Criteria
Required input fields are marked with an asterisk (*)
120 © 2014 CA. ALL RIGHTS RESERVED.
Step 2: Source Criteria
Class value of Entity covers all other classes
121 © 2014 CA. ALL RIGHTS RESERVED.
Step 3: Target Criteria
Class value of Entity covers all other classes
122 © 2014 CA. ALL RIGHTS RESERVED.
Step 4: Match Criteria (Optional)
Match Criteria are not required for Unmanaged Relationships policy
123 © 2014 CA. ALL RIGHTS RESERVED.
Step 5: Relationship Scope
Identify which Services to apply the policy against
124 © 2014 CA. ALL RIGHTS RESERVED.
Step 6: Confirm
Service Modeler Demo /Instructor-Led Lab (5-10 minutes)
126 © 2014 CA. ALL RIGHTS RESERVED.
Manual Service Creation
Manually create this service. Append service name with your initials
1. Create Child Service: OnlineOrderingCustomer
2. Create OnlineOrderingService
3. Create 2 groups4. Drag and drop CI’s to define
service
Service Modeling Free Lab (20 minutes)
128 © 2014 CA. ALL RIGHTS RESERVED.
Service Modeling Lab
Create a manual service model Use the relationships and propagation rules to manage state propagation of
infrastructure events
Create a Custom (Group) Policy in your Service Model
Create an Escalation Policy / Action to Escalate only when the service state is degraded
Advanced Topics
Using Event Enrichment to change severity of Alerts
131 © 2014 CA. ALL RIGHTS RESERVED.
Example Alarms for which Severity could be updated to ‘Down’
132 © 2014 CA. ALL RIGHTS RESERVED.
Solution: Update Spectrum alarm severity
Alarm Severity update treated as an enrichment policy
Enrich Spectrum DEVICE HAS STOPPED RESPONDING TO POLLS events to change the Severity of the alert from Critical to Down
133 © 2014 CA. ALL RIGHTS RESERVED.
Update Spectrum alarm severity
Open the Event Policy editor, enter the search criteria for Event Pattern 1 :– Summary="DEVICE HAS STOPPED RESPONDING TO POLLS" or Summary="CHASSIS DOWN”
NOTE: you can match on multiple events with the logical OR syntax, so one policy can match many events.
and then click the Search button and verify your pattern matches as expected
Click on ‘ Create Policy’
134 © 2014 CA. ALL RIGHTS RESERVED.
Update Spectrum alarm Severity
From the Create Event Policy page, enter a policy name such as ChangeSev2Down, then choose Filter Events - Include Events radio button, and then click Next >
135 © 2014 CA. ALL RIGHTS RESERVED.
Update Spectrum alarm Severity
Complete the enrichment page as follows:
Type: Script
Script Path: none
Script Name: none
136 © 2014 CA. ALL RIGHTS RESERVED.
Update Spectrum alarm Severity
Configure the Severity as desired (Minor, Major, Critical, Fatal (aka Down))
137 © 2014 CA. ALL RIGHTS RESERVED.
Update Spectrum alarm Severity
From the Select Data Sources Page, select the Save and Deploy policy radio button, select the Event Management MidTier Connector data source from the Available Data Sources list, click the right arrow to move it to the Selected Data Sources list, and then click Finish.
Wait 1 minute for the event policy to reload automatically OR restart the CA SAM Integration Services (IFW) and CA SAM Event Management services.
Integrating SNMP Events(time permitting)
139 © 2014 CA. ALL RIGHTS RESERVED.
SNMP Connector Overview
A generic data collection connector, receives SNMP traps from any SNMP-capable product, transforms the traps, and maps the generic SNMP attributes to the USM model
Each domain manager requires a separate connector policy that dictates the varbind to SOI attribute mappings
Connector policy is XML-based and extremely flexible, offering ability to parse, normalize data
140 © 2014 CA. ALL RIGHTS RESERVED.
Steps for Creating SNMP Connector Policy
1. Direct SNMP traps from domain manager to the SNMP Connector
2. Review the raw trap data received by Connector
3. Modify <SOI>/resources/Core/CatalogPolicy/snmp_policy.xml to
determine how CIs will be created from traps
4. Create the snmp_policy.APPLICATION.xml to determine format of the
Alerts created from traps
SOI 3.2 includes a UI for creating and configuring this policy
5. Review results
141 © 2014 CA. ALL RIGHTS RESERVED.
1. Review Raw SNMP Trap Data Received by Connector
142 © 2014 CA. ALL RIGHTS RESERVED.
2. Modify snmp_policy.xml to Create CIs
143 © 2014 CA. ALL RIGHTS RESERVED.
3. Modify the Alert EventClass to Format Alerts
144 © 2014 CA. ALL RIGHTS RESERVED.
SOI 3.2 Event Policy UI EnhancementQuickly and Easily Map Raw SNMP Trap Values Through the UI
Troubleshooting
146 © 2014 CA. ALL RIGHTS RESERVED.
Six core Services– SOI Manager (“CA SAM Application Server”)
Tomcat application and core engine for SOI (listens on port 7090 for debug/admin pages)
– UI Server (“CA SAM User Interface Server”)
Presentation Layer – hosts web GUI and launch point for console
Also a Tomcat instance (by default listens on port 7070)
– IFW aka Integration Services (“CA SAM Integration Services”)
Java application that hosts all connectors running on a given machine
Communicates to SOI MGR via ActiveMQ messaging buss
– Event Management (“CA SAM Event Management”)
Controls communication with the local Event Store, event queries, etc.
Must be deployed wherever there is an IFW instance
– UCF Broker (“CA UCF Broker”)
Supports the “Unified Connector Framework” (aka Catalyst)
Southbound integrations – listens on port 8020
– Store Indexer (“CA SAM Store Indexer”)
Indexing of USM data for display in USM Web View
Must install on same host as “UI Server”
SOI Installed Services Tour
147 © 2014 CA. ALL RIGHTS RESERVED.
Troubleshooting SOI Connectors
Connector architecture is very asynchronous– First must isolate the root cause domain
SOI Manager,
Connector Framework (IFW)
Domain Manager
– Use DEBUG mode of Log files to isolate
148 © 2014 CA. ALL RIGHTS RESERVED.
Where are the Log Files?
<SOI>\tomcat\logs
– Log files for SOI manager
<SOI>\jsw\logs
– Service Logs
<SOI>\log
– Connector Logs
<SOI>\log\debugData
– Detailed debugging files containing CI files for the different connectors
<SOI>\SAMUI\log
– Logs for UI server
149 © 2014 CA. ALL RIGHTS RESERVED.
Configure Connector debugData
Config file - <SOI>/resources/log4j.xml
Make sure the following “logger” sections are uncommented
Files will be located in <SOI>/log/debugData directory
150 © 2014 CA. ALL RIGHTS RESERVED.
For More Information
To learn more about DevOps, please visit:
http://bit.ly/1wbjjqX
Insert appropriate screenshot and text overlayfrom following “More Info Graphics” slide here;
ensure it links to correct pageDevOps
151 © 2014 CA. ALL RIGHTS RESERVED.
For Informational Purposes Only
This presentation was based on current information and resource allocations as of August 2014 and is subject to change or withdrawal by CA at any time without notice. Not withstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this presentation remain at CA’s sole discretion. Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA will make such release available (i) for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as part of CA maintenance and support, and in the form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis. In the event of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall govern.
Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this presentation “as is” without warranty of any kind, including without limitation, any implied warranties or merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA is expressly advised in advance of the possibility of such damages. CA confidential and proprietary. No unauthorized copying or distribution permitted.
Terms of this Presentation
Copyright © 2014 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belongto their respective companies. CA confidential and proprietary. No unauthorized copying or distribution permitted.